I read an article about React Native(http://blog.scottlogic.com/2015/03/26/react-native-retrospective.html), and I'm also experimenting it at the moment.
During a few days of experiment, my feeling is switching from excited to concerned.
As React Native is focused on V in MVC, but IMHO I'm more keen to share code in M (and Services) across platforms. I'm happy to have native views (xib for iOS and layout for Android), as I think they are meant to be platform specific, and that is the main reason for going native rather than hybrid and HTML5. The story is different for Model and Services though as they are common and better to be shared across platforms.
It might make sense to have shared code between Mobile(React Native) and Web(React), but it is too early to tell now.
How do you think? And I look forward to hearing your thoughts.
With React Native you can write all of your views in Obj-C (Cocoa, XIB or Java) if you want. It's actually not that complicated.
However, some of the greatest strengths of RN is that it uses JavaScript. This allows you to write all of your business logic ("M" as you put it) in JavaScript and now share that across mobile platforms (iOS & Android right now). Of course, if your business logic is decoupled from the UI (as it should be), you can then even share that on the Web as well.
Before this, if you wanted a shared common library of business logic between mobile platforms you had to either write it in C++ or perhaps use something like Xamarin (C#).
I'm not sure if that is answering your question or perhaps agreeing with some of the things you are talking about haha. AFAIK, React Native is definitely solving the right pain point because it's so flexible, it let's you decide what that pain point is. :)
Related
Sorry if the title wording is not clear enough. I need to deploy a very simple app on Android and iOS for a partner company (app does not need to be in App Store or Google Play) to control some machinery via bluetooth. Interface needs to be very basic and only contain a couple of buttons and some text labels that display some information (and be able to read a QR code).
We are not a mobile development company, thus I don't have any experience building apps like this, but the required functionality seems simple enough to at least look into what needs to be done.
Now, the problem is that I only know C/C++ and Python (moderate experience with the Qt framework) and am not really willing to learn both Java and Swift. I might consider learning Swift specifically for a simple project like this, seeing as iOS development is very much tied to their platform, but Java is out of the question. I've looked around and there seems to be a way to write both of them in Python and deploy to each platform, but something tells me it's not really worth the incredible amount of problems that could arise. I need your help with some advice on how to handle this project:
Can a cross-platform app be developed with python(or C/C++) and deployed to iOS and Android (thus halving the overall development time) whilst keeping a sufficiently tidy aspect and bluetooth communication?
If not, can I develop an Android app using C/C++ or Python without immense hurdles? I'd prefer Qt as i'm already familiar with the framework, but i suppose anything does it.
When developing an Android app under point 2, is it possible to see how the app looks like without installing it on the phone for every change in code?
Sorry if the post is too long, am really curios how difficult would a task like this be. I dont want to waste my time learning 2 new languages for just this project nor do i want to end up delaying the partner company with beginner problems caused by my scarce knowledge of a new language.
I really wouldn't suggest cross platform for this kind of project. The bluetooth stacks and APIs are going to be tremendously different, minimizing ability to code share. The UI stacks are completely different. Really using anything but the native tools on iOS can be particularly tricky. Python in particular is hard, because its not meant to interact with either platform. C would be easier, as both Java (via JNI) and Swift (via objective C to C bridges) can call C code. However the UI layers of the two are so different that it would only be useful for business logic, I would still recommend writing the UI in the native platforms.
If you were going to try and do cross platform, I'd suggest react native and javascript, merely because it's the most mature of the cross platform products. That said, their bluetooth stack is likely non-existant or poorly developed because its not the type of thing used by many of the type of apps that choose react native, so you'll likely have to dive into the deep end and learn how to make modules.
Given that this is going to be a company specific app not on an app store- do you actually need to support both OSes? Or can it be done on company devices of a single type? Pushing back on that product requirement might be your best bet.
I'm looking into creating an app using Reactive Native.
One of the reasons it's appealing to me is that it's already battle tested by apps like facebook.
With that said, facebook doesn't use react native for the whole app.
I can't help but wonder - in what parts did facebook use native code (java / kotlin / swift) instead of react native and for what reasons?
I am not sure what parts of Facebook are React Native or not, but we can assume a very large portion of each platform is not, especially looking at its need for native API's. React Native sounds so awesome, "Learn once, write anything". Unfortunately, as we have seen in many cross-platform solutions over the years, it is easier said than done. I think the way Google's Flutter is attempting a cross-platform solution is most likely the best yet, as it builds into native code for each platform without an abstraction layer.
Back to React Native:
Pros:
If you are a JS guy you should have a natural leg up due to your
underlying knowledge.
Cost-Effective, one solution fits all.
Simple UI (See below).
Large active user base with plenty of development resources.
Cons:
Immature and behind when updates come out to the various SDKS's (Or modules SDK's)
Lack of security, open-source, less robust.
Slightly slower, especially during thread initialization.
Poor thread and memory management.
Simple UI, Looking to do something more complex, it might be a challenge to achieve just what you want.
Heavy usage of native code will still be expected.
Non-native API and SDK support instead utilizes Native Modules.
Blackhole debugging, longer debugging.
Is Facebook, could always be abandoned.
I'm developing an app for iOS and android that identifies songs. We have a matching engine in c++ that works well, but my question is about the rest of the app. We have a user interface design that allows the user to record, match and save, as well as share, edit, and see their recordings.
I'm not a coder - just a designer- and I'm getting conflicting advice about how to implement. One person wants to do the majority of the interface in c++ with just a thin native GUI skin, while the other says we should write in native IOS (swift) and Android and only have the engine in c++. The argument for c++ is it will be a single code base to maintain - it would include doing the sharing, storing history, displaying sonograms, etc. The argument against is that in fact it will not be easier to maintain, and will also create a lot of problems making calls, for example, between the interface and the sharing module.
Hope this is clear - it's a very hard thing for me to assess as ignorant as I am! Any advice would be greatly appreciated.
In my opinion, the way to go is to write the GUI the way it was meant to be. Native iOS/Android will yield a much better user experience and will allow you to use the platform latest and greatest way of implementing a UI.
Also, I am assuming that the engine will probably not be developped by the same people that develop the GUI itself, so the argument that it would be simpler to have a single code base doesn't really make sense.
Another solution could be to use Xamarin, so that you can consolidate iOS and Android development, while still having a common C++ engine.
Edit: Typo
I created an Android app. While creating one specific app was an interesting challenge, I'm now looking into creating a group of similar apps.
I'd like to create a group of similar Android apps and then move on to creating the same on tablets and iOS... (anything mobile).
I've considered doing so with a product called PhoneGap or doing a web based mobile app. Both of these options seem less than ideal. Doing the Android app I've been frustrated by Java's lack of control and low level constructs. Moving to something like a web based app seems like the exact wrong direction.
C++ is my language of choice. It has the ability to work at a low level, is highly portable across platforms, and has significant support for generic coding which would be useful for generating a group of similar apps. However, the Android documentation suggests to not use C++ unless your goal is porting existing code or dealing with computationally heavy tasks.
I'm leaning towards using C++ anyway, but are there other options I've not considered?
Thanks
You could in theory write your logic in C++ and then have UI layers on top that make use of it. If you are really comfortable with C++ that might be the way to go.
Almost any other parts (networking, UI, animation, etc) are better off being done in the native language of the platform. Use of cross platform solutions always limits you in some way, and usually leads to an application that is not as good as it could be for any platform.
Well, Google's recommendation to not use C++ is based on the following, I believe. C++ is low level, so you can get extra performance out of it if you know what you are doing. Google makes the reasonable assumption that many programmers do not. It is easier for an inexperienced programmer to do harm in C++ then to get a performance boost.
But, if you know what you are doing, it can help you. UI elements on both iOS and Android are implemented in their main language (obj-c, and Java respectively) so there is not a great way around that, but you can write core logic and other functions in C++ and it will be portable between them (iOS can use C++ directly and Android can use it via the Native Development Kit).
There are a few other options available. The one I ended up using is Appcelerator Titanium but please stay away from it. If your project gets complicated or large at all you will hate yourself for choosing it, as I did. Another interesting one that uses C++ instead of Javascript is Marmalade. I haven't used it though, so I can't comment on it.
A non-free solution that I hear good things about is Xamarin, who have ported both environments to C# and a .NET using Mono. However, you still have to write two versions of your code for the UI as far as I can tell.
I'm doing some initial research on smart phone development, and I noticed that Android and Windows Mobile both support c++ for application development. I was curious if anyone had any experience trying to manage shared files between both Android and Windows Mobile, and to what extent that code can be shared? e.g. no user interface can be shared, but web service and business logic classes can be shared, etc.
I can't speak to the WinMo side of things, but on the Android side you should really really really avoid using native code for anything except performance-critical processing algorithms. JNI/NDK stuff does not play nicely with the normal Dalvik lifecycle and can be a source of all sorts of ugly unpleasant bugs and memory leaks. From what I understand there also aren't on-board NDK libraries for more complex high-level functionality like HTTP (just more basic/performance-oriented libs like libz and OpenGL), so you'd probably have to compile that stuff and ship it with the app as well. I would definitely not recommend coding your web service classes in C++, even if it's technically possible; it'll be less buggy and nicer to write C#/Java and you should be able to make mostly the same architectural decisions for consistency.
That said, if you have a performance-critical bit of image processing code or the like, it actually can be fairly straightforward to get that working across Android to other platforms (I've seen it done quite well with some image-processing C code used in an iPhone app and then used via the NDK in an Android app).
Check the documentation on the NDK for details on what it can (and can't) do, and see similar SO threads like this one.