So apparently the experience never gets really good as opposed to native iOS development where once you get to a certain level you don't spend that much time chasing weird build errors.
- write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature)
- write native UI code using native tooling, and call the business logic library from there.
But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.
- It forces you to think about your business logic vs. UI structure.
- It forces you to make your core logic library easily testable.
- Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly.
- The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM.
- Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well.
Biggest issues?
- Getting inflexible people to learn anything other than JavaScript.
- Getting slow compile times under control.
- Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase.
- Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.
Electron is a UI 'framework', so bringing it up is kind of a non sequitur. Your approach of a C++ core is entirely compatible with an Electron UI.
I worked on a project that had its 'core logic' implemented in C++, which we then ran that on the web in Javascript, for the same portability reasons.
I believe it was due to JNI but my memories may be wrong.
We used C++14 which has a pretty good standard library and plugged the holes with some parts of Boost and then standalone libraries like SQLite, json11 and others to provide missing functionality.
We actually used their own Djinni library on one of the projects and it worked well - but even at that time the Dropbox team wasn't maintaining it at all since they never used this approach beyond the short-lived Carousel app.
I suspect it will be the best way going forward, other approaches all have serious issues.
I have intentionally kept my very specific use case mobile app very very simple and not gone deep on the magic edge cases. It is a private app and will never be on the store. It is basically used as a QR code scanner to track equipment.
I'm sure that if you have a lot deeper/larger apps you'd find more to complain about, but so far I'm happy enough with going from zero to full fledged app in about a month of work.
IMHO, the boilerplate argument with Java is kind of outdated (Project Lombok and modern java solve a lot of that).
What is wrong with react natives official documentation? I think what many mess up(me included) is to look at the wrong version of the documentation. I guess that could be a little bit more obvious.
edir: oh, typescript! Yeah, that is a little bit more troublesome; https://facebook.github.io/react-native/blog/2018/05/07/usin...
If you already know React/Redux/etc, perhaps.
Else "Ready to go" after reading about several concepts, libraries, and systems and getting how the work together, what performance pitfalls they have, etc...
I guess I’m asking; what other solution have you found that solves everything for you?
You can bring in libraries of course, but even for a large iOS project it's unlikely (and probably unnecessary) to have more than a handful.
It was from someone familiar with GUI programming, who wants to try doing it in React Native and suddenly finds tons of new concepts to keep in mind (compared to common native GUI frameworks/libs).
So appending '--typescript' is troublesome and not obvious? Like this?
react-native init AppName --typescript
That's it. I never knew in 2019 that adding an extra flag would be 'troublesome'. The description of your installation of a React Native and TypeScript project in 2018+ is greatly exaggerated.
Nothing worked.
Is the flag generating a project that works without anymore tweaking/setting up? If so, my reference to the blog is not accurate.
Also, a better reply would be “oh that article is not accurate anymore, now everything is setup for you I’d you add this flag!”
There has to be a better way to write mobile applications. Is that Ionic? I don't know.
https://developer.apple.com/tutorials/swiftui/
There may be a chance of it being adapted for other platforms in the future.
Maybe other developers who really really love Swift and SwiftUI might port it to their preferred platforms. :)
that’s not the hard part, and apple knows it ^_^
it will be interesting when/if someone manages to get something close to apples implementation working, though my guess is they will have a “not fun” time trying to reimplement every ui interaction satisfactorily...
Flutter looks interesting, going to check it out.
In the end one wants a true "write once, run everywhere" framework, not write the business logic and then write the UI 3+ times for each target platform. Ionic delivers on this front, but am curious to see if Flutter takes it to another level (blazing fast dev/reload cycles and native performance in production sound quite appealing).
That said, who knows what the demo app was done with. If there is lagging scroll performance, it could be a lot of things.
I will say that figuring out where the performance problems are would be pretty enjoyable in IDEA. The tooling there for performance is quite good.