I'm curious what you guys think of PWAs vs React Native? Is there a clear advantages of one over the other?
React Native at Instagram
121–130 of 238 posts
Re: React Native at Instagram
#122So I see they have a lot of code reuse between RN iOS and RN Android. How much, if any, code reuse can there be between React Native and React (proper)?
You can't re-use the UI portion but all the business logic, API calls, stores, socket connections, etc...
For Sleeperbot it's 50% code-sharing between desktop / mobile, and then 95% between iOS & Android.
Re: React Native at Instagram
#123@martinbigio here in case anyone has questions
Probably OT but a bug that's been driving me crazy for a while now. When I open Instagram it reloads the feed every time as if the app had been purged from memory. This means if I accidentally close the app and reopen it my scroll position is lost and thanks to the sort algorithm the feed order has changed and I can't get back to where I was.
Wow, sounds like they've really managed to bring a web-quality experience to native.
Excellent work.
Re: React Native at Instagram
#124Earlier quoted context omitted.
This is one of those Android design decisions that Google probably wishes they could get to do over again. The DEX header file format allocates only 2 bytes to hold the number of methods the app can reference. This was a very short sighted decision that has come back to bite them repeatedly. It would be interesting to know why they only allocated 2 bytes instead of 4 which would have given them the ability to referen…
It's not that easy, and not just one field. DEX uses a method table, listing every method with an ID, and using in the rest of the file only that ID to refer to it. This ID is limited to 2 bytes. Obviously, thats an issue, but short of using varint or straightaway uint32 there's few alternatives. And those use either more CPU or memory.
Thanks for the correction. Here's a transcript from the Android Developer podcast, courtesy of http://blog.osom.info/2014/10/multi-dex-to-rescue-from-infam..., talking about the issue with an Android engineer:
>Tor: So [regarding] the infamous 64k method [issue].. I understand that it is a dex file format limitation.. which is a short integer. Do you have plans to address this somehow, by either change the dex format or some other way?
>Anwar: So we've talked about revving DEX, so that limitation doesn't exist anymore. And there's a couple of reasons we haven't done that: one, there're other things we would like to do better as well, including supporting new language features. The other reason is - it doesn't help us with devices still in the field. It's hard to go and say "by the way, we're going to upgrade your runtime.." So what do we do in order to address that? We will do the DEX byte code [change], but I think there's sort of building block that we needed first - what we're calling multi-DEX. And the idea is.. here's something people were doing - they were breaking up their files into multiple DEX files (each of which exceeds the 64k limit), the main classes in DEX file could see the classes and use them in sort of references rather than loading those classes and having limitations in how you can use them. They will go and use reflection to find the boot class path and modify it to include their secondary DEX files. So this is kind of hack, but a necessary one for them.
>What we're doing in L is in runtime we will have a native support for multi-DEX. All your DEX files that you have in your app will get dexopt-ed or compiled by us and collapsed into a single .oat file which is a binary file we generate.. ..And we have a support library on top of that.. ..if you have multi-DEX it will work on older releases of Android back to Ice Cream Sandwich.. will work on Gingerbread too, but we're only validating back to ICS. So once you have that, than that free's you in the future to do the DEX byte code change, and then something that partitions it and runs on the existing [devices]..
One interesting note is that he mentions that they'll hopefully have the DEX revision by M. Well, we're on N so it looks like they missed that target date. Perhaps O will finally get the long awaited DEX file format revision.
Re: React Native at Instagram
#125Earlier quoted context omitted.
This is one of those Android design decisions that Google probably wishes they could get to do over again. The DEX header file format allocates only 2 bytes to hold the number of methods the app can reference. This was a very short sighted decision that has come back to bite them repeatedly. It would be interesting to know why they only allocated 2 bytes instead of 4 which would have given them the ability to referen…
It's not that easy, and not just one field. DEX uses a method table, listing every method with an ID, and using in the rest of the file only that ID to refer to it. This ID is limited to 2 bytes. Obviously, thats an issue, but short of using varint or straightaway uint32 there's few alternatives. And those use either more CPU or memory.
So why can't Google create a new version of the dex format, update Android Studio to generate it, and update the store to accept and distribute it to new devices? Seems easy enough for Google to be able to do.
Re: React Native at Instagram
#126I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and metho…
There is no practical difference between single and multidex. Recent versions of Android are even better at creating these dex files effectively so users won't even notice the difference.
Most of these methods are typically contributed by dependencies, not by the app itself.
Re: React Native at Instagram
#127I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and metho…
This is one of those Android design decisions that Google probably wishes they could get to do over again. The DEX header file format allocates only 2 bytes to hold the number of methods the app can reference. This was a very short sighted decision that has come back to bite them repeatedly. It would be interesting to know why they only allocated 2 bytes instead of 4 which would have given them the ability to referen…
> This is one of those Android design decisions that Google probably wishes they could get to do over again.
Doubtful. This decision is what allowed Android to perform reasonably even in the early days circa 2008. Without such a restriction, it's possible that Android couldn't have competed with iOS on performance and die as a consequence.
It's easy to make fun of technical decisions made ten years ago, try to put things in perspective.
Besides, even today, this 65k limit is barely a minor annoyance that only a very tiny percentage of Android apps ever hit (and there are easy workarounds).
Re: React Native at Instagram
#128@martinbigio here in case anyone has questions
Thanks, Martin, for appearing here. I've read a few times that apps developed in React Native have an odd look-and-feel, or had noticeable touch latency, or aren't performant enough or native-quality. Every time I tried an app built using a hybrid framework, it felt second-tier.
Has that been your experience? When you moved any UI from UIKit or native Android views to React Native, was it worse in any way? Did it require a lot of work to get back to native-quality UX?
Re: React Native at Instagram
#129I really want to look at React Native, but every time I pull up my Facebook app on my iPhone 6, it can take upwards of 30 seconds before the interface is useable. That's on a very fast connection. So to me the FB app is so slow, it makes me hesitant to give React Native much more thought as you'd figure the FB app would be THE showcase app for it. Maybe I'm the only one?
Someone correct me if I'm wrong but AFAIK the Facebook app isn't really using react native yet, just in very small parts (event dashboard). The rest is still plain old swift and objc.
They have added quite a few screens on react native now. They don't use Swift at all right now.
Re: React Native at Instagram
#130Great engineering. Instagram always runs snappy and also with low bandwidth (>1Mbit/s). Meanwhile Snapchat does not even know how to download first clicked story video first.
Though Instagram stories are pretty slow to load.