SEEKING WORK - Remote
Mobile Developer based in the Caribbean (reasonable rate :)) Skills: Native iOS / Android, React Native. I've worked on projects using RxJava, Firebase, MVP architecture.
I also have experience with client side development React / VueJS / Redux and server side development with Node.
You write Android apps the same way you'd write them in Java and the Android SDK but with the Ruby language. The quickstart gives you an idea of how to translate some of the Java to Ruby but you'll still need to learn how to build Android apps with Java.
The first module I tried was react-native-image-picker and yes it returns an object with base64 encoded data. What I do with this data is first, resize the image then display the resized image in an ImageView then upload the resized image to Firebase Storage.
I did just that. I created a native Android project that selected an image from the image picker and displayed it in an image view. I tested it with a few images and it worked. Even the image that crashed the React Native app.
"Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having React Native made it worse.
"
That's an interesting idea. The code to select and resize the images are native third-party plugins so in this case I am not sure anything more could be done.
I thought maybe the problem was that the app had to switch to another app to select the image. I reimplemented the code using a pure JavaScript plugin based on React Native's CameraRoll API to avoid switching apps and it still crashed when the image was selected for processing.
I've dabbled with NativeScript a bit. It does seem a bit closer to the underlying platform but from my experience of it, it felt incomplete.
I first tried the Angular version before the final version of Angular was released and I recall occasions where the documentation for NativeScript was behind the actual API. I had to look at the actual code samples to figure out the correct APIs.
The next time I looked at it, I tried the regular JavaScript version and I recall having trouble deciphering the API for the SideBar plugin.
This left me feeling a bit insecure about the product. It looks to have a lot of potential though but it could use a bit more polish and better documentation.
That's a fair point about the opportunity to build some performance-tuning muscle but I imagine to do that would require solid knowledge of both React and Android. Where do I start? I am more inclined to go towards the native Android side first.
Aa a follow up, I just did a test with a native Android app doing the same thing: getting an image through an Intent. With the native Android app, the same image that was crashing the React Native app doesn't cause any problems.
This article is spot on. I love the metro UI but in its current form it's not quite ready for the desktop. Some things that were easy to accomplish before are now made more difficult. The removal of the start button is one. Having to click the corner of the screen to access the Start Screen is frustrating. The target to click is essentially smaller which requires more precision and effort to hit.
Closing apps is also more difficult. On the desktop you just click the big red button and the window disappears but in metro you're required to click the top of the screen and drag the app to the bottom of the screen. It's a lot more work and it's frustrating.
The interesting thing about all these frustrations on the PC is that on a tablet they'd be great! Metro is a great tablet UI. It's optimized for touch. This is clear so why force it onto the desktop? This clearly demonstrates the difference between Microsoft and Apple's philosophy on user experience. Microsoft is cannibalizing the desktop user experience to realize a utopian vision of one OS to run on all devices. If Windows 8 on tablets is a massive success then maybe to MIcrosoft that would have made it all worthwhile. People could always go back to windows 7 on the desktop if they prefer to. Maybe this is Microsoft realizing that we are indeed in a Post-PC era and it needs to succeed in this space at all costs!
Amazon!I think amazon knows what it takes to challenge the iPad. Their success with the Kindle shows that it can produce a quality hardware product. Also, the fact that they've said very little about their plans suggests that, unlike HP they aren't going to release it until it's ready. And when it's ready, just like with the Kindle, they'll promote it on the front page of their retail site and provided that it's a good product and it gets good reviews it will take off.
I don't see Google giving away phones for free. This would be seen as anti-competitive and unfair by their partners and they would drop android and seek alternatives like windows phone. Google wants a world where Android runs on different handsets by different manufacturers. This is part of why the Android ecosystem is so resilient. Failure of one manufacturer is not going to destroy the Android operating system as there would be other companies to pick up the slack. Google cannot afford to fight the mobile wars on its with strong enemies in Apple and Microsoft who would love to see Android die.
I also have experience with client side development React / VueJS / Redux and server side development with Node.
email: [email protected]