Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am having experience in iOS application development in native platform and tools. I have a requirement to port an existing native application to Xamarin platform so that it is only a matter to maintain single code base for multiple platforms. My existing application has following features.
Api calls using AFNetworking Library.
Local caching of data using
Core Data, NSIncremental Store. Core Data migrations are implemented
to support versioning. Also complex mappings are done using many-many
relationship, one-many relationship etc.
Asynchronous and
synchronous network calls.
Listing items using table view controller
with Search Controller. Pagination is implemented in these view
controllers.
One of the views in the application is rendered using
Open GL.
Can all these features be perfectly ported to Xamarin. Does Xamarin provide apis for these features? Any help will be appreciated.
First of all, let me tell you that Xamarin is not about a single code base for all the three platforms, but you could share a good amount of code between the three platforms. But that will depend on each app.
To the best of my Knowledge AFNetworking has a partial support. This is repo for it: https://github.com/paulcbetts/AFNetworking-Xamarin . But if you plan to port your app to xamarin/ cross platform. I would recommnend using a C# variant, check if Modernhttpclient will help you?
Local data caches are very well supported
https://www.nuget.org/packages/SimpleStorage/
https://github.com/akavache/Akavache
Async progrmamming is one of the strengths of C#/xamarin.
https://developer.xamarin.com/guides/cross-platform/advanced/async_support_overview/
TableViewController and Pagination is supported
Hope it helps you to get started with porting your app.
If you aren't using any third party libraries you shouldn't have any problems porting this application to Xamarin.
Before you begin I would advise that you think about any functionality that you can wrap up in a core project and inherit in your iOS and Android projects so that you have the maximum amount of code re-use. Thinking ahead will save you a lot of time.
Also be cautious when using table and collection views. I've previously encountered a solution which was holding on to a lot of memory because the table view cells weren't being deallocated correctly.
Considering you are having experience in iOS application development in native platform and tools. there is going to be a huge learning curve.
Shifting from Android studio to Xamarin(VS2015) was a hectic job for me.
But maintaining the less code for multiple devices is really fun using Xamarin.
your first requirement is answered by this github link here
Asynchronous and synchronous network calls are easy to handle as I am using it in my project so that is not going to be the problem.
Happy Coding
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I develop an app for both iOS and Android, and I'm loon'ing for the best way to share code between this two platforms.
What I would like to do is creating all the View (UI part) in native but share the code for the logic (controller + model).
With all I found, 3 things seems to be quite good :
1) C++ --> Build library file Using c++ For the logic so I'll be able To use the .dll files in the 2 platforms
2) Azure mobile apps services. Is it possible to habe all the logic in a webservice? The issue is that if I dont have acces to internet, my app will be unaivalable, right?
3) I hear a lot about React native used by Facebook, but it seems to be used to create the UI, but I prever create it in native. Can I use react only for logic?
It seems like you have three options:
1. C++
You can't just have a compiled .dll and expect it to work for iOS and Android. They both have to be compiled in different architectures and it has to be a static library on iOS.
Dropbox's done it this way, and they've put up a lot of notes and example code, and code you can use so you can take a look.
Pros
• Pretty straightforward after you manage to set it up
• No additional layer of dependencies, bugs, etc (like in case of Xamarin/React Native)
Cons
• Setting it up and using it needs a lot of extra work: you need to setup additional compile steps and write wrappers for both platforms.
• Some other challenges you're surely going to meet when trying to compile the same code for two different architectures
Here's a SO post on how to do it in detail...
2. Xamarin
This option seems to extreme to use in this case. You're forced to use C# and introduce another layer of dependencies and bugs. You said you don't want to use another language for UI so I wouldn't recommend it.
3. React Native
Now this is a viable option. You can write scripts in JS and use them in native code in both Android and iOS.
Here's an article on how to share code with code examples...
Unfortunately it uses React Native for UI, but you can easily call React Native functions from native code.
There are a lot of downfalls to using this, including the fact that the calls are asynchronous as they're executed on another thread, so you would have to implement some kind of callback system for functions that return something.
Pros
• Seems to be easy to set up and write
Cons
• You'd have to implement a native callback for every function that returns something
• Using it has a lot of downfalls that the document describes:
• As events can be sent from anywhere, they can introduce
spaghetti-style dependencies into your project.
• Events share namespace, which means that you may encounter some name
collisions. Collisions will not be detected statically, what makes
them hard to debug.
• If you use several instances of the same React Native component and
you want to distinguish them from the perspective of your event,
you'll likely need to introduce some kind of identifiers and pass them
along with events (you can use the native view's reactTag as an
identifier).
Conclusion
I think I'd go with C++, mainly because a big company (Dropbox) tried it and succeeded and actually uses it in production. You could try React Native as an experiment, it would make a great study case!
I'd say that putting the "core" logic into a separate library is a sensible approach.
You are not the first who wants to do this, and I highly recommend looking at Djinni. It's a tool to accomplish just that. You can define common interfaces and datatypes and fill in the native parts. Communication is possible in both ways.
It's not as easy as writing the whole thing natively at once, but it supports clean design which you might benefit from anyway.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Doing some investigation on the feasibility of using QT/QML for an upcoming project. Client wants it initially on Windows and Mac desktops, with the possibility of iOS and Android down the road. They would like to know that what we build will move relatively easily. I'm not much of a desktop programmer, but what I see is that QML is designed to work with C++. As a result, it should be relatively easy to build an app that runs on Mac and Windows, and iOS will accept C++, so I can't see a lot of roadblocks there. But I'm confused about Android. I see folks talking about building an Android app using QML, but they seem to still be using java; I gather it uses the NDK in the background.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java? The app is not a simple one, so we are going to have to provide some logic outside of QML, at least, it sure looks that way. While we might save time and $$$ by using QT to not have to go native on the desktops and iOS, I see a problem with Android down the road.
But if you write an application that has QML for the front and, and C++ for any guts not covered by QML, can it work on Android? Or do you need to rewrite the C++ piece in java?
It really depends. You may need to go through the Java interface where the Android platform does not provide direct and public API for certain functionality. One example is low-level IO operations, like writing the serial port for usb-serial devices, but there is more to it.
In general, what Qt modules and third-party software based on Qt do is to use the QAndroidExtras add-on module introduced in Qt 5.2. This will allow easy backend integration into your C++ logic.
With that in mind, you could hide the Java implementation details in the background while you still maintain the C++ interface to QML. Therefore, it should just work that way.
Please see the following documentation to get the grasp of it:
Qt Android Extras
Here you can find one of those nice examples:
Qt Notifier - Demonstrates calling Java code from an Android application.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been using the flash pro for 6 years now, and I find it very easy to create any kind of application and game (except 3D ones). The flash pro says that is can compile cross platform natively in Android (and iOs too), so am in a dilemma (or trilemma), should I use:
1. The flash pro IDE which I know very good
2. Should I learn Eclipse which I hear is ideal for Android apps or
3. Should I make the app with HTML5, jquery mobile, etc and compile it with PhoneGap?
The app I was to develop is quite simple, it has a list of POIs, categories, (from online database) and it shows them on map (flash pro may have to use stageview for that), so the graphic processing required should be minimal. It may also cache some POIs when downloaded on phone.
Please answer the question in relation to:
- Speed/responsiveness of the app
- How much "native"/professional the app will be
- Feature-wise, would all the features be there
- Debugging
Thank you,
Panos
You are always going to be able to get the best results with the most native approach (eclipse) as long as you can handle the IDE and language. You have a good deal of experience with flash and if you don't have much or any with Java you may have trouble getting into using Java.
Here's a simple breakdown though:
Flash:
Great for apps that serve as a web frontend.
Supports most common android features.
Doing anything heavy in processing or too custom tends to get bad performance.
You are abstracted from what the app is really doing and therefore have less control.
Java:
You are using the native language and therefore can use android to it's fullest extent.
You will find plenty of help for any problem you run into and it's much easier to debug more complicated apps.
Better performance in most app usages, especially for more complex apps.
Not cross-platform though you don't seem to care about that.
PhoneGap:
I have no experience for this but I would assume it's similar to the Flash approach.
Probably really good for Web Frontends.
The choice is really just dependent on what you feel would best suit your current knowledge and goals for the app.
I would strongly recommend just learning Java and using Eclipse as it will always be as good and responsive as you can design it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm new to iOS/Android development so I would like to know what is the usual practice of developing an app for different platforms - is the whole code rewritten or the possibilities are used to choose some language, C or C++ for example, and keep most of the work in this language and then cover it with system specific stuff in corresponding language? I know about Android NDK and having C/C++ code in your iOS app, but the question is - is this usually used in practice - maybe later some other platforms might be added? The classical example would be the Angry Birds, of course, which I have even on my "smart" TV. Would be good to hear guys experienced in this area since I might be in the middle of making a decision. Thanks!
You should go check out the Xamarin studio. It allows you to write code in C# and reuse up to 80% of your code between the platforms. They have some videos and tutorials for how to best write code that can be reused.
You might try Qt framework as it's native to Symbian, officially ported to Android, and unofficially ported to iOS and Blackberry. It's a C++ IDE at http://qt.nokia.com
Better yet, if you're into that kinda thing, try PhoneGap here: http://phonegap.com/ This will allow you to write your "app" code in HTML.... yes, HTML, and port it to just about anything. Things that are normally OS-dependent are basically wrapped in PhoneGap's API including hardware: http://phonegap.com/about/feature/
THe classical example would be angry birds? I've either hit a time warp to 20 years in the future, or you're thinking way too small.
But yes, it is quite common to write the majority of logic in C or C++ and just write system specific stuff and/or UI in the native language.
There are several cross-platform solutions on the market. Some of them use Java and C#, they usually are integrated with the common SDKs (such as Visual Studio, Eclipse). Some of them allow to easily develop and distribute web-apps using HTML5, Css3 and jQuery combination.
You can just surf for them on the net. I suppose it's not allowed to mention them here. If I'm wrong I will post the name of some of the most known solutions that I tried.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Coming from J2ME programming are there any similarities that would make it easy to adapt to Android API. Or is Android API completely different from the J2ME way of programming mobile apps.
Actually the Android API is much more powerful than the J2ME.
It is much easier to create an application for the Android.
Using the J2ME you are limited to simple forms due to the absent of swing-like libraries (though now there exists a library called LWUIT, avoiding the need to recreate from scratch a swing-like library).
In Android you will be able to create complex form very quickly, and software package for the android SDK is easy to install (while in J2ME you have to install the wireless development toolkit from sun, or install one of Nokia's, Samsung's or SonyEricsson's... it gets a bit confusing sometimes).
The things I had to change when switching from j2me to android were:
1/ The font and graphics class is easier to use on j2me. The API is more thorough on Android, but also more complicated.
2/ If you are used to the database storage of j2me (RecordStore), well you can forget it in Android. You will have to use a SQL-like databased, so be prepared to rethink your data model.
I've also found the path from Java ME to Android to be pretty simple. Here are a few things I've noticed:
There is ONE ui draw thread in Android. You have to be aware of the difference between calling postInvalidate and invalidate on Views to force them to update.
The actual bit-wise graphic manipulation is very similar. I was able to port large amounts of custom J2ME draw code by writing a few shims for drawRect and drawImage.
Android's UI library is much more extensive, much less useless, and much more complicated than Java ME's
Threadwise, you have to be much more careful about thread saftey with Android. In Java ME you can get away with not making methods synchronous or variables volatile most of the time. Not so in Android.
I will say, on the whole, that Android's UI library fails a critical test. I call this the "roll my own" test.
Your UI library fails this test if it takes me longer to complete a detailed task task (say, changing the background on one individual menu item) than it would take me two write my own Menu from scratch. Android fails the "roll your own" test by a factor of 3 or 4. In fact, if you look, the majority of the questions on this website are "How do I make the Android UI toolkit do my bidding?" questions.
Android is an amazing platform and it has been worth every frustrating moment I've sunk into it. It is, however, a young platform, and needs some serious work in times to come.
A good start would be to watch the Android architecture videos and look at some of the documentation.
http://www.youtube.com/view_play_list?p=586D322B5E2764CF
http://code.google.com/android/what-is-android.html
Google is very good about documenting. From what I've heard Android very very similar to J2ME in its goals. It may be slightly different in programming style and structure but if you have J2ME experience you should be more then ready to move on to Android.
Good Luck!!!
Well, you may not actually need to adapt.
There is a good chance that a J2ME stack will become available for Android before long since Android is not supposed to become as restrictive of third-party runtimes as the iPhone.
I know one guy who has been working on just that:
http://justanapplication.wordpress.com/
Now, of course, that doesn't mean you shouldn't have a look at the Android APIs and application lifecycle.