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.
I had the wrong understanding of how it worked (I come from a Rails/Javascript/Ruby background), so thank you for the explanation, it illuminates a lot.
Let's run with the absolute sense. Getting 10x more front page posts will be a challenge requiring dozens of attempts and you need 100s on the front page just for awful numbers to become bad numbers!
Doing 100 front page posts this decade seems wildly optimistic, that'd be you on the front page every 10 days and it is highly unlikely HN even wants to talk about any person that often.
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.
"
Seems like it can't be that hard to use that native code you wrote in your test in the react-native app though. Write the final image to disk. Load the image in an image view. Never pass the data through the JavaScript bridge.
Maybe this is your opportunity to create "SilkOdyssey's Badass Image Picker for RN, now with less crashy". It seems like you're partway there already. Maybe fork or PR the one you're using.
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.
Just a wild guess - you said opening for processing. Depending on what you're doing with the file and how you're opening it the whole data get's passed over the bridge resulting in some catastrophic memory allocations. I would recommend tapping into the bridge communication and start checking if everything stays where it should. Some picker modules tend to send base64 encoded file beside the URL.
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.
You definitely will want to write images to file, then pass the file path over the bridge. That's an easy solution.
I've been using React Native cross platform for over a year, and it has a ridiculous number of issues, but they're trade offs. There are benefits that come with it. React Native is just another tool, evaluate it as you would any other framework.
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.
It might help with some of the performance issues you encountered.
Even if you decide to abandon React Native and just do Native Android or iOS, you are going to have to deal with performance issues at some point in your career.
Are you sending an image bitmap in the actual Intent? I'm surprised you're not having it break when sent to Android's IPC mechanism which has fairly low size limits.
I would use a Content Provider to share the image instead.
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!
"The target to click is essentially smaller which requires more precision and effort to hit."
It's actually the opposite, the virtual target area extends beyond the screen to the bottom and left and that area has no boundaries. In other words, you can move your cursor in the right direction and if you keep moving you are guaranteed to hit that area. Experienced users will just 'flick' their cursor in the general direction knowing they are going to hit it.
I also have experience with client side development React / VueJS / Redux and server side development with Node.
email: kelvin.pompey@gmail.com