71–80 of 335 posts
This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…
TLDR - it's too hard to find senior C++ mobile devs. I'm more intrigued by AirBNB moving away from React Native - the linked article says "RN was too small a component to bother supporting, and the developer experience wasn't up to par", but I'd like more detail than that. I've been working with Flutter for the past 6 months, and it would definitely be my "go-to" for any mobile application. To be fair, I did spend 2…
AirBnB has a series of in depth blog posts about their decision to abandon RN. In particular this quote seemed extremely worrying to me: > While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit…
Wait, React Native uses JavaScriptCore on Android?
I've been really pleasantly surprised lately how much code can be effectively shared when using Xamarin Forms. I haven't encountered much problems, except when dealing with tricky stuff like the Android camera API's (which, from what I understand, is problematic in native Android code as well).
Since it's not stated in the article, I am going to assume they haven't tried Xamarin. I've been really pleasantly surprised lately how much code can be effectively shared when using Xamarin Forms. I haven't encountered much problems, except when dealing with tricky stuff like the Android camera API's (which, from what I understand, is problematic in native Android code as well).
In my experience, using a "cross-platform" framework means that you'll write the code not once, but three times: once for the cross-platform framework, and once per platform (Android / iOS) given all the quirks and unavoidable customizations that will need to be made to make your app function correctly.
Earlier quoted context omitted.
I wonder if that is a symptom of C++ having many recent revisions, thereby influencing, misleadingly, the definition of "experienced".
Yeah, I have 15 years of C++ experience, but not since 2012. So with C++11 and C++17 (and soon C++20) my skills have not aged well, even though I can still write C++03 just fine. It's no wonder 'senior' devs prefer to use plain C, where even C11 is not that different from C99.
I don't think that's necessarily the case. C++'s famed backwards compatibility, source of so many issues, is also a fabulous strength. There's nothing stopping one from writing C++03, while gradually adapting C++11 and beyond as time/circumstances permit (which is what I'm doing at my job, maintaining a massive legacy codebase while stymied by slow uptake on newer compilers by my corporate overlords...)
> It's no wonder 'senior' devs prefer to use plain C
Not this senior (in years, at least :)) dev. I've tasted RAII and I can't go back...
Since it's not stated in the article, I am going to assume they haven't tried Xamarin. I've been really pleasantly surprised lately how much code can be effectively shared when using Xamarin Forms. I haven't encountered much problems, except when dealing with tricky stuff like the Android camera API's (which, from what I understand, is problematic in native Android code as well).
How about running a background service to synchronize a local folder of content with a remote server? Making sure the background service is launched correctly upon startup? Integrating with the OS's native sharing features with other apps? And so on. In my experience, using a "cross-platform" framework means that you'll write the code not once, but three times: once for the cross-platform framework, and once per plat…
The last 2 apps I've been working on were Xamarin apps and I'd guess the first app probably shares 80% - 85% of the code base and the second app 95%. The first app less, because the client wanted a specialised camera module, which required me to create bindings for the Fotoapparat [1] library on the Android platform.
Both apps used Xamarin Forms. The platform specific code, all things considered, is really small.
I should note I've also done a lot of Swift & Objective-C development in the past and a little bit of Java. I also tried Xamarin around 2013 and back then the experience wasn't as good as it's right now.
My major gripes with Xamarin currently are: - The IDE becomes slow sometimes (fixed with a restart) - The IDE sometimes has issues connecting to the Android emulator for debugging (often restarting the computer fixes this).
I should also note that if I were to write an iOS only app, I'd definitely use Swift (I love working in Swift, more than C#, Objective-C, Java, …). But for multi-platform apps, currently my tool of choice is Xamarin.
---
[0]: https://docs.microsoft.com/en-us/xamarin/cross-platform/maci...
I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…
How does that work out when things change over time: requirements and the platforms themselves?
I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…
How does that work out when things change over time: requirements and the platforms themselves?