I'm working on building an App with Xamarin.Forms that will periodically (re: every second) potentially do something, regardless of if the application is in the foreground or background. Think something like a Timer/Clock.
I've found plenty of information on the Android side of things. It looks like prior to 8, you can run it in a service -- and at 8 or later, you'll need to run it as a Foreground Service.
e.g.
https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/services/foreground-services
From what I can tell, if I want to write any kind of controller to initialize this service (only if necessary in my client app), I'd have to add Mono.Android to the main shared library, which seems like the wrong thing to do, since the iOS version would ALSO have this dependency.
However, the iOS documentation is a little spotty when I search for it, as are best practices. I'm not sure if the correct route is to do Backgrounding -- or if that'll close things down.
e.g.
https://learn.microsoft.com/en-us/xamarin/ios/app-fundamentals/backgrounding/introduction-to-backgrounding-in-ios
It seems that Xamarin.Forms has come a LONG way with how things work in the past few years -- even 2016 to 2017 has a number of things changing. The web is crowded with tons of different (and no longer valid) tutorials on all of this.
Right now, I have a singleton instance of a state-tracker that can be called to update every second (or other controls, i.e. skip forward one minute).
Are there any best practices for cross-platform foreground service development? My best guess at this point is to publish Messaging events from that Controller, with specific code inside the main bodies of iOS and Android projects, which will then "know" how to create the appropriate services and then call the singleton instance of that state-tracker I mentioned before (which runs every second).
Are there any best practices or anything else that have something as simple as this published? Periodic calls, while the service is "initialized," to run in the background and make calls against a state service to track/announce different states, as necessary.
Xamarin.Forms is ONLY user-interface cross platform development, and as Xamarin.Forms is based on .Net you can also use everything available in .Net for cross platform development. And that is as far as it goes out of the box. Some cross platform features not available in .Net are covered with official and unofficial plugins like Xamarin.Essentials.
To conclude unless there is a plugin for what you require (and I am not aware), you need to use the native Android and iOS functions. Also you are limited with their limitations.
There is no way to predictably run the app on iOS in the background. While there might be some workarounds like using the push notifications none of them are something that will work well in general situation.
Related
I try to develop my app that only use ReactNative for UI but still use (in Android) Activity/Fragment/Service classes for business logic. Same thing for iOS, still use Controller, etc for business logic.
But when I search on Google, on Youtube, all tutorials I found only tells how to make app that has only UI thing, pure ReactNative code. My questions are:
Is it possible to only make UI with ReactNative but still keep using native API e.g. Activity/Fragment/Service (Android), Controller (iOS) in my mobile project?
If it is possible, how? Any good tutorials (both Android and iOS)?
According to this article, I wouldn't recommend using native modules for EVERYTHING (Activity/Fragment/Service..)
The performance bottleneck often occurs when we move from one realm (native or javascript) to the other. In order to architect performant React Native apps, we must keep passes over the bridge to a minimum.
If you are interested in knowing, this is how bridging works
Is it possible to do what you want? Yes.
But if you are going to have the activities, services and business logic you might as well do it all in native.
Depending on your app necessities react-native will be suitable for you or not. If your app depends highly on hardware (bluetooth, accelerometer,etc), needs high frame rate performance (like a game) or heavy interaction with other apps (content provider) or device system (like alarm manager) then I wouldn't recommend using it. Otherwise, it is an amazing option.
I’ve started to dig into integrating React Native in existing apps, and I mean real industrialized apps (iOS and Android version of a same app) that we wish to refactor with as much RN as we can for bringing code bases together (there is also an existing web version).
We are pretty convinced that including multiple RCTRootView sharing the same bridge is the best approach for us, starting from the basic content views (where sharing code bases is easier and more profitable) and iterating to turn more and more parts of app in RN (Animation, Navigation, …).
But when we’ve investigated this approach, several questions popped out, both technical and organizational.
First of all, although we don’t want to be iOS-first or Android-first, the Android platform doesn’t seem to have the same maturity of the iOS platform for this kind of work. We faced some problems like:
The ReactRootView doesn’t follow the React lifecycle, unlike iOS’s RCTRootView, there is no API to update props : https://github.com/facebook/react-native/issues/6303
It’s impossible to include a ReactRootView inside a native scrollview. This limitation exists from the day one of the Android release (see https://github.com/facebook/react-native/issues/9022)
The following is not really a “problem” but it adds some doubts about the Android support.
The iOS part of the integrating doc clearly mentions that it’s possible to init a view using an existing bridge (initWithBridge, the API is explicit too).
On Android, the same doc mentions that multiple views can share the same ReactInstanceManager, but if you expose 2 components in your bundle and use it, you have to call twice startReactApplication and you’ll see 2 lines in Chrome console
Running application "XXX" with appParams
Running application "YYY" with appParams
Sounds not very optimized to me… Did I really create 2 entire “RN apps” here ?
That being said, we are looking for feedbacks and answers :
About the Android platform, is it reasonable to synchronize the refactor on both platforms or we’d better turn the iOS app into RN and then the Android one ?
How far can we go in RN views displayed simultaneously ? 10, 20 views at a time ?
Our app is “data-oriented”. Is it a good idea to move the data-fetching in a Redux app in the RN world first ? I guess we have to expose data and notify store updates to the native world: what is the most efficient way to do this ? (Native modules makes the communication in the other side easy, native toward RN, but they seem not helpful for this purpose).
Also, how to organize the VCS ? Is moving the 4 code bases (iOS, Android, Web and the RN bundle) in a mono-repository a necessary move ?
I have been developing a much-revamped version of an earlier android application. So many additions and changes to the infrastructure, UI, and general organization were necessary that it was far easier to start from scratch with the new application and transplant some of the guts from the old one rather than trying to understand everything the previous developer wrote and incrementally perform smaller surgeries.
I have the source code from the previous developer, and it contains several activities, fragments, classes, etc. that I know likely are not being used in the final build. To make the transplant process as easy as possible, is there an easy way to find out which of the above components are simply not being used in the app?
A couple ideas that immediately come to mind are:
stepping through everything in a debugger and taking note of which components are used (this seems like a super inefficient and terribly tedious process)
add a log message to each component's onCreate/instantiation code and then run through the entire app (more efficient, but still a pain)
Is there an easy way to do this?
I am an intern at a company trying to push an android and iPhone out out within the next 5 months. Today, I received information about my first "real" assignment which will entail porting the iPhone App to the Android platform. Here's my problem though: I've never seen a single line of Objective C code and I only just started programming in Java and for Android devices last wednesday.
So how do I go about porting an application? Where do I start? How do I best organize myself and get an overview of which tasks to complete and when to start working on them ?
tldr; How do I port an application to another platform?
Word porting means in effect creating an application on another platform (in another language if needed) that maintains the same functionality. As iOS and Android use different languages and internally very much different operating model, you cannot simply take iPhone code and translate it line-by-line into Android.
What you do need to do is analyse the functionality of the iPhone app and create an app for Android that will perform the same functionality. Do not approach this as a direct "porting" project, but rather as a new development project. You may be able to translate some business logic one-for-one - but anything related to the user interface (and, most likely, to any back-end server communication if you have any) will need to be written from scratch. You may encounter certain things that are present in an iPhone but are not supported at all in Android, or are very complicated to implement, so try to think how to substitute them with whatever Android does support.
The biggest problem you'll encounter with Android is the multitude of screen sizes and versions, each of which may behave differently and support different things. I suggest you start from the beginning and do one screen at a time, adding functionality step-by-step until you get the desired app.
5 months is a long enough period of time to complete the job for almost any app. Good luck!
P.S. I have gone through this exercise myself: having an iPhone app I had to "port" it to android platform. Using the approach I described, it took me about 2 months to complete the android app, which initially took about 3 months to create on an iPhone platform.
What are the key differences between Android, iOS and Blackberry OS in terms of level of accessibility by application developers (i.e. access to the video input, sound input, phone functionalities, to which extent, etc.)?
PS: Assume latest version of each OS.
EDIT: Can someone turn this into a wiki so we can compile answers from people that don"t necessarily have experience in all 3 plaforms.
I'm not familiar with BlackBerry, but on Android and iOS you can access just about anything. Until recently iOS had some restrictions about camera access (see this), but I belive those have been solved. Because Android is open-source, you can theoretically go as deep as you want as far as accessing the hardware, but you may or may not be able to get any deeper through the standard Android API than you can through the iOS API.
On Android, you can do a lot more to override default functionality. For example, you can create your own launcher screen or phone application. The iOS approval process wouldn't allow these kinds of applications.
API hardware access really isn't an issue on either platform, the bigger concern is overriding default software (almost never possible in iOS) and what types of applications iOS allows.
Each platform has its own nice and bad parts. I have been working on both Android and BB. I wish I could take only nice parts from both to create a platform of a dev dream! :)
For instance, I could take these features from BB:
The greates feature I like in BB is the simplicity of the application architecture - you can always count on your main UIApplication instance - OS never kills it.
Also I do like the simplicity the Dialog class provides - it is very easy to implement business logic related to user choice - while Dialog screen is shown the code execution just stops and waits for user input.
From Android I'd take the following:
Network communication. On BB this is a real nightmare (BES, BIS, WIFI, Direct TCP without APN, Direct TCP with APN, WAP, WAP2, Unite - who's next? :)).
For file manipulations you just use a native/usual Java API.
Nice looking UI components are available right out of the box.
I should add I'm not happy with GPS related stuff on both platforms, however maybe it is due to GPS hardware limitations rather than API creators.
Thanks!
BlackBerry is a pain, once I made a project for it (the JDE version was 4.7 back then) and it didn't had an ArrayList. WTF?