React Native for Android

Post by lispm » Wed, Sep 16, 2015, 5:52 AM UTC

ufmace wrote: post #238

lispm wrote: post #216

Earlier quoted context omitted.

That's why Common Lisp / CLOS has functionality like * CHANGE-CLASS (change the class of an object to a different class), * update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed), * update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),…

Which can be really cool, but has its downsides: Hey cool, I can change these classes live! Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem. 2 years later... What's causing this super-weird bug? It's like the code isn't doing what it says at all. 1 week of debugging and head-banging later... Oooh, something got screwed up in that runtime class change code.…

Post by tmail21 » Wed, Sep 16, 2015, 6:27 AM UTC

lhorie wrote: post #103

jbigelow76 wrote: post #35

Question for everybody doing some sort of cross platform mobile dev. How common is it to have NO experience with a platform's native libraries? In other words you didn't go from ObjC or Java to React Native/Cordova/Xamarin to try and re-use code but because you know JS or C# and weren't concerned about learning the native platform. For any that started out with no native platform knowledge did you start to dip into i…

I got into native development with no experience in the iOS/Android APIs, coming from a web dev background. I did know Java and C from working on side projects, and read up on Objective-C before, though. At my previous company, all the developers doing native work had no prior experience w/ mobile development (i.e. they primarily had backend C# experience) I dabbled w/ Cordova and friends before, and did some work to…

Post by ufmace » Wed, Sep 16, 2015, 7:21 PM UTC

lispm wrote: post #241

ufmace wrote: post #238

Earlier quoted context omitted.

Which can be really cool, but has its downsides: Hey cool, I can change these classes live! Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem. 2 years later... What's causing this super-weird bug? It's like the code isn't doing what it says at all. 1 week of debugging and head-banging later... Oooh, something got screwed up in that runtime class change code.…

Is that something you've experienced?

Post by anezvigin » Wed, Sep 23, 2015, 1:54 PM UTC

amelius wrote: post #211

exogen wrote: post #193

Earlier quoted context omitted.

It's because anyone who has done any complex web app development knows that you don't have one button changing color. You have 100+ UI components whose state may depend on one another, and as the DOM nodes composing those UI elements get state attached to them, it's EXTREMELY easy for them to both (1) get out of sync, and (2) thrash and re-render entire trees of the DOM unnecessarily. This is a real thing that happen…

Yes, I understand all of this. It can work for small websites. However, the technique cannot uphold for larger systems. For example, consider writing a word-processor using this style of programming. If the user is writing a 10-chapter book, and every character entered by the user requires a visit of all characters in the book, that is not very usable. So even from a practical viewpoint (not just theoretical) it is n…