The Desired Functionality:
User A is running your app on an Android or iOS device. User A can automatically find and communicate with other nearby (< 20 meters?) users B and C (Cross-Platform), whether they're running Android or iOS, and without any of the users having an internet connection (Offline).
I believe this is a commonly desired functionality, and having a definitive answer to this question would be a great boon to the mobile development community.
Further requirements/things you'd like to have, in order of importance:
Single Codebase (or at least sharing 90+% of code) for Android and iOS, e.g. through Xamarin or something similar.
Automatically choose the best (perhaps going down a list of preference) signal to use, e.g. choosing WiFi direct or bluetooth (similar to AllJoyn, Multipeer)
Use only Free (or free for certain classes of user) libraries
The Question:
How to achieve the desired functionality?
Sub-question 1
Is it even possible?
Answer: YES. Apps like Firechat and Spaceteam do it, therefore it must be possible.
Rejected Possibilities:
Multipeer: iOS only, doesn't achieve Cross-Platform.
Alljoyn: iOS bindings are Objective-C only, doesn't achieve Single Codebase.
Mono.Zeroconf: Supposedly would require separate platform implementations, so don't achieve Single Codebase?
Open Garden SDK: Would be a great solution, except it doesn't actually exist yet.
I've been researching this topic for several days now, and I haven't been able to find a definitive answer. Part of it is probably that people use so many different terms like mesh networking, ad-hoc networking, zeroconf, DNS-SD, etc., which makes it difficult to search.
If you're interested in some of the research I did on stackoverflow and elsewhere, here are some notes and links (I'm limited in the number of links I put directly in this post).
Not sure if this is what you are looking for but I would highly recommend Xamarin with the library ZeroConf which is native and has Xamarin support.
https://github.com/onovotny/Zeroconf
It works great and that gets you close to your unified codebase with a native and uniform way of discovering other ZeroConf devices.
Edit: It looks like the ZeroConf library only supports subscribing to ZeroConf services and not publishing also and I think you will need publishing as well. But it seems other users have requested it so it seems like a feature they will be adding.
Related
I know this is way too general, but I have a reason. I am looking forward to make a simple app that can transfer strings from my mobile device to my TV. I wish to transfer this data over Wi-Fi, provided that the TV and my phone are on the same network. Now, the Android Documentation for the P2P Wireless APIs is DEAD. It even uses some deprecated implementations, and to worsen that up, nobody cared to provide an up to date documentation for carrying it out in modern day programming.
All I want, is a reference to a reliable source that might be helpful in understanding this. I added the compose tag, again, so that the info is conveyed that the app is built using a declarative paradigm, unlike the traditional android system. The sources may still be using the old android system (I, however, would prefer a Compose app). If nothing, at least point me to the correct (and updated) documentation, if it at all exists.
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.
In the recent weeks I have been busy with the issue of cross-platform development. That starts with the problem that I had the feeding to write a wrapper for the communication-API of MoSync (I don´t knew this SDK and others for cpd before). It should be used in our Java environment for instance to easy create a bluetooth-connection to different phones and so on.
For me the other question is now, how I can use such SDKs like MoSync, Titanium and others in a existing project? In my opinion it is not possible. Either you develop nativ or with a cpd-framework.
I would also be interested in when do you recommend this frameworks (I know already that there are some other threads about this). I personally would say that there isn´t a great future for this SDKs because of technical drawbacks and dependencies. In addition, the market for cross-platform solutions (hybrid, interpreted, cross-compiler) is at least as fragmented as the market for mobile operating systems themselves
What are your experiences?
Martin
Cross-platform implementations of any type, on mobile or anywhere, are primarily to reduce the time to market. That statement may look like oversimplified, but it more or less holds true. So, the ideal situation to use it would be to have an application/game that maybe, uses the common denominator of features across the smartphones, which could include touch, a decent UI, the network, maybe the accelerometer in some cases LBS. So, you land on multiple phones in quicker time and reduced development cost.
If you are looking to utilize a lot of hardware specific features, then we land into what's commonly known as the unknown territories. Then you have to do what people always do, gather more information about the landscape of phones to target and see if the "chosen framework" has the power to dish out the features on those platforms. In this case, you cant possibly deploy one off-the-shelf.
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?
I've done plenty of iPhone work, never anything with Android. On iPhone, it was a few months in before I discovered the Three20 library (which is awesome) and began moving my code over. I don't want to make the same mistakes moving to Android, so my question:
Do android developers commonly use 3rd-party UI/networking libraries like Three20 on iPhone, or do they take the ones out of the box? I realize that there is an effort to port Three20 to Android, but that's not my goal per se. I just want to know if the out-of-the-box UI/networking/navigation libs you get with android are considered sufficient for most android apps.
Thanks!
I never had a problem using the ones out of the box.
Perhaps, as Pentium10 mentioned on a comment, I read some open-source code and get some ideas but the final answer to your question is no.