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 9 years ago.
Improve this question
I have been given the tasks of speccing a mobile application, which will need to run on approx. 1000 devices. These devices already exist, and consist of iPhones, BlackBerrys, Androids, Windows Mobile and Netbooks. The application will have simple reporting capability, and a collection of forms.
Anyway, the obvious solution would be to develop some browser based solution, although given the occasionally connected nature of the devices, there's a potential for data to get lost / not saved.
So instead of creating a complex application for each platform, I was thinking we could build what is effectively a form generator, with basic offline storage capability (text files), designed to run on each device, and have the device generate a form, based on for example an XML file that it could request from a server somewhere, resulting in minimal specialist development costs, and the ability to run most of the logic from the server end, with the devices being dumb clients that render forms and upload the data when there is an available connection.
Anyway, my question summarised is, how have you made the decision on supporting multiple devices for your application. Is this always an unavoidable problem, and you just have to make the call to support 1 or 2, or pay for developers to write code for each platform, or alternatively supply pre-installed devices to the company?
Many thanks
James
Have you considered building a web-based HTML5 application with the ability to store data locally etc. so it can work offline too? This is probably the best way to build portable apps as long as you don't need to take advantage of specific features of the phone's API (e.g. the GPS). This would be an ideal way to do an application like the one you describe.
I have not used this so cannot vouch for it in any way however the RhoMobile project looks worth investigating
You may also want to check out the following SO questions
Technology to write iPhone, BlackBerry and Android phone at the same time?
Is there a multiplatform framework for developing iPhone / Android applications?
Since your application mainly involves UI forms, you can go for J2ME development that can give you device general application to an extent. But yes, writing a full fledge application that will work great with each device is a big issue and you will need to write device specific application for optimal leverage of the device.
There are already many products that do what you want. If not, as was mentioned RhoMobile (http://rhomobile.com/) is an option.
You should really browse the different app stores out there, there are a number of options:
Canvas (http://www.gocanvas.com), eXzact (http://www.iformbuilder.com), Pronto Forms (http://www.prontoforms.com/). In addition Google Code has ODK (http://code.google.com/p/open-data-kit/wiki/ODKCollect)
Good luck! I've worked on several projects where we decided to just build a builder of some sort (MDA, forms, etc.). Building the builder is always more difficult than you expect.
Related
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 2 years ago.
Improve this question
I want to develop a game where you go to the website and open the mobile app corresponding to it you scan the QR code on the website and synchronize the website and the app.
So the game will be on the website on the screen and the user will move their mobile phone and depending on how they move their hand the game on the website will react.
So the game will be developed with unity, is there a way to synchronize the website and app this way continuously without delay? and how?
I know the question is vague but it's not something within my expertise i just wanna know where to start my research, few keywords would help a lot. It's a new project in a field i haven't worked in before.
I want a game in a website to be in sync continuously with variables sent from a mobile app without delay.
This is a very unspecific and open ended question, to which you cannot get a good answer based on how many open variables there are. So basically you want to make a game that runs on a website, and then want to make a mobile app that is able to communicate with the game.
The only way to do this is to use a server with a backend-api, which you can then fetch and push data from and to your webgame/app. Basically the server is your communication tool between webgame and app.
You need to make an app though which serves the mobile phone's orientation data to the server. How you do this and what kind of server software is best to use fully depends on what your skillset allows for, what the specific constraints are and what parts of the project already exist (what framework does the app use (react native for instance), what platform does the app run on...).
I can only tell you that this is by no means trivial. Let alone making an app is a ton of work, but writing a backend for the server, an app and a game that runs in a browser is a huge project! I would highly suggest you perform more research on server-client communication and app development, because the scope of this project is based on how you phrased your question probably far bigger than you imagined.
I am working on iPhone app development currently (primarily native app using Obj-C and some web app using jQTouch). My question is regarding the future of this space;
In say 3 years time, what do you think would be preferred (native or web app) ?
What are the strengths going to be for native app (I know for certain types like Games, people prefer native than browser-based, but will that remain that way forever)
Some people say HTML5 will replace native app development, as it will be "code once, run anywhere" kind of thing (like common for iPhone, Android, BB phones). So do you think HTML5 can completely eliminate native app development.
I know the mobile space is constantly changing with new technologies coming up regularly and hence one cannot say with certainty what the situation will be 3 years forward. But I think there are projections being made by many agencies. So are there any reputed ones which can give a general idea or some sense of what might happen in future.
My main aim is what exactly should be my focus (like what technology/platform/native-web apps), if I want to look at the mobile space for the next 5-10 years.
Please provide as many responses as possible.
My 2c.
The popularity of web based apps will continue to grow. Whether it will pass native apps I don't know. For them to be on par in terms of numbers in 3 years doesn't seem unrealistic.
Native apps have the following benefits:
Better performance (potentially)
Fewer restrictions on accessing device resources
Greater control of execution of application
HTML5 won't completely eliminate the need for native apps (see point 2 above). Even Google who are creating an entirely web based OS (ChromeOS) don't seem to be looking to get rid of Java/Dalvik for Android based dev.
"code once, run anywhere" is very unlikley for anything but the simplest of apps/functionality.
"Code once, compile for each supported platform then test everywhere" is much more realistic.
I'd recommend focusing your education on what makes a great mobile regardless of platform and looking at web based development.
1: Native. It will always be preferred, as it is the most convenient type of app. Personally, I only have one web-app on my phone.
2: The iOS-framework. It is really the largest upside of the native apps. And the fact that they are easily downloadable through the App Store.
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 4 years ago.
Improve this question
I am trying to create an iPhone app for a large website (as big as amazon.com) and it involves using cookies and what not to get authenticated via the Apache intercepter and access the web services exposed by the main website.
For that I am looking for strategies to go about developing it. I am new to iPhone development and I am mostly looking for some architectural guidance.
Does anyone know how services like eBay and Amazon work seamlessly across the website and iPhone app?
I'd say it depends on your technical background and your app design. But basically you'll be developing a big API for your big site, exposing the data you want to be read by your iphone app. You'll have to get your hands dirty and delve into iphone development, but you know, just the basic stuff, like retrieving that data, generating your views dynamically according to this data and there you go! So, i'd say that this is will be only a simple, compact client for your big site, I mean, it should't be just as the same as the real site, you can only pull out the big features/functionality and port those to the app, or balancing some features with another ones only capable of be done on the iphone (geolocation, gps, camera, etc...). If you choose this path, the services stuff could be the hardest part, the client side will be easier (new grounds for you though).
You can even fake an iphone app with jQtouch, if you are on the web side on css,jquery and feel comfortable in this area. As a drawback you are not going to be able to sell this "app", since it'll be only a web page optimized for iphone (and even so, you'll miss the ipad users). If you choose this approach you can even go for the real thing with phonegap, compiling your web application (with jQtouch, or name any tool or web framework) into a native app, being able to sell it or distribute by apple in it's store.
my 2 centavos.
As big as amazon.com? Amazon has poured millions of hours into their web site, and they have had to deal with a myriad of issues:
Massive volumes of traffic. This alone encompasses a world of scaling challenges that would have most architects running screaming from the building.
An incredibly diverse business allowing sales, marketing, I.T., delivery chain, partners, suppliers, corporate and private customers, dozens of LOBs, etc., etc., all to interact with the web site.
The site must work across platforms, browsers, countries, tax and legal agencies, currencies, regional sales and marketing arms, etc., etc.
An army of programmers, architects, designers and testers working on infrastructure, UI, business integration, performance, security, privacy, data management, data mining, auditing, etc., etc., all working to contribute to a common customer experience.
In the face of all this complexity, their seamless integration has, I suspect, been built at a gargantuan expense.
Is this really what you meant?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I tend to believe that developing mobile applications in an enterprise environment is best suited by developing intranet web applications. That said I have been asked to think about whether there are specific enterprise applications that could only be accomplished or would be more successful as native applications. I am curious as to what the Stack Overflow community thinks.
Note: As an organization we primarily use BlackBerry devices but are other platform curious.
A few of domains seem better suited to native apps off the top of my head:
Applications with disconnected data sets. Mobile apps cannot always count on having an Internet connection. Native apps handle that case well. This is especially true for data entry tools. If you receive a call in the browser while entering data, the work may be lost if the page reloads after relaunching Safari.
Apps that need the user to upload media like photos, videos, and sound recordings. Currently, there is no way to upload local iPhone media via MobileSafari. Native apps handle this case. Insurance and real estate might be good markets to target with this.
Advanced processing apps. For example, if you wanted an inventory management app that could read barcodes using an iPhone's camera, a native app can process imaging data much faster. Any augmented reality app would run best as a native app.
High memory apps. When other apps run, Safari still chugs along in the background. If those apps need more memory, Safari will release the RAM allocated to a "tab's" page contents. That page then reloads the next time a user opens Safari. If your app needs lots of RAM, then making it a native app gives you higher priority than remaining a web app.
Needs to run in the background as a service. Starting with 4.0, of course, you can build IT asset tracking services, GPS logging, corporate messaging (think Microsoft Office Communicator for iPhone, etc.), regulatory compliance monitoring, order notifications, custom SIP/H.323 endpoint for a VoIP switch, etc.
Large datasets. I believe Safari limits SQLite databases to 50 MiB max. For a native app, the available space will be constrained primarily by the available space on "disk."
Actually, just looking through the API. Any API not available via a webapp would be a good place to start. I'm being coy, here, regarding 4.0 API's that are currently under NDA. :)
That said, SproutCore Touch provides a good web platform that is specific to touch interfaces.
While there may be some specific enterprise applications that are best as a native app I can't think of any concrete examples.
However while I agree with you about intranet web apps are typically better, I think that all depends on who its better for. Obviously intranet web apps are better for development, and better since they can be cross playform, however I think that virtually all apps are better native for the end user. Don't agree? Look at the number of successful iPhone and Android apps that are out on the market that are just native portals for some site's data. Users far prefer the way a native app works over a mobile browser.
Also another thing I would take into consideration is if the app already has an intranet web app in use designed for desktop systems. If there is one, I would go the native app route since the users on the other mobile platforms can still access the desktop version. However if there is no universal portal I would consider doing that vs native.
The ideal would be to do both.
Have something like a secure restful interface that feeds json or xml to a native mobile application. The restful interface would be easier to start with, easier to test, easier to prototype, and easier to change. It would also make life infinitely easier when the data needs to be synchronized, backed up, cloned, or when the phone gets lost/broken/stolen/upgraded.
And then, having a native application built in addition to the restful interface would also allow for the use of the Native UI environment. It could allow the app to work offline. It could use its own notification-system, without going through SMS/push-mail. And if some of the relevant data was indeed mirrored offline, the application would become also more responsive, and much easier to use with other apps (where it comes App-functionality sharing, I'm only speaking for the Android SDKs here, and mostly the future version of the iPhone SDK, not the Blackberry yet). The end result would probably a much cleaner and much more pleasurable application to work with, assuming it could also be done as a Native Application.
I would recommend that the decision regarding whether to create a web application, native client, or both, should be made after understanding the problems you intend to solve and examining the needs of the end users of the application. It would be impossible to suggest that you can answer the technology question without understanding the user problem.
In Chapter 8 of "About Face 2.0: The Essentials of Interaction Design", Alan Cooper talks about software postures. One of these postures is called the "Sovereign Posture." This posture represents an application that is typically used full screen and for long periods of time, and represents the primary application for a given user. Visual Studio and Eclipse are good examples of sovereign applications for developers. If the interface in question is a sovereign application for a user, that strongly favors a native client.
In a specific enterprise example, a service desk application is a sovereign application for technicians, but it is a transient application for users. I would suggest that an ideal factoring of such an application would be a rich native application for both desktop and mobile devices for technicians, and a self service web interface for users. For the technician, the advantages of a native application outweigh the costs of deployment, given that there are generally fewer technicians. Also, the technician may be working on a network problem, and the offline reliable nature of a native client allows the technician to continue using the application even when the network is unavailable.
If the user spends more than a few hours a day interacting with the application, then strongly consider the advantages of a well designed native client. If there are multiple users, consider how each role uses the application, and perhaps you end up with a hybrid model. Your UI strategy should always be based on examining use cases over following gospel from either camp, and should be focused on the user experience, not developer convenience.
The pros of native app development are primarily around getting access to hardware features that aren't accessible through web APIs, obtaining native performance benefits (such as in action gaming), instant access to paying customers through a platform store (such as iTunes), and security situations where you don't trust the browser or how it's handled.
The cons of native app development are that you lock yourself into a potentially proprietary code platform, write a bunch of device-specific code, and you're vendor locked. Code is harder to write, much harder to deploy, and you stand the chance of having the rug pulled out from under you. (Yes I'm looking at Apple, but could happen to any proprietary platform.)
Web apps by contrast are based on technologies that are widely known and easy to deal with - HTML5, CSS3, JavaScript, and excellent libraries such as JQTouch are available to help. Well-designed web apps for the most part will not care if you're on a Blackberry, Android, or iPhone, and will work on many of the older and less capable models as well as the newer ones and devices we haven't even encountered yet, without having to recompile or refactor (or at least without having to do a great deal of recompiling or refactoring...) And there are some hardware features accessible, such as GPS through the geolocation API.
But on the other hand web apps may not perform well with large data sets or high computational requirements. If you're building a commercial app with financial transactions, you very likely will have to roll your own payment system. And you have to trust the browser security as well.
All in all, most apps are going to make the best sense as web apps. However, many web apps can be made to function to be almost indistinguishable from client apps. With some HTML5 offline storage, CSS3 and JS functionality for transitions and behaviors, many business apps can be made to be indistinguishable from native clients.
In iPhone's case we can take it further: Adding a 57x57px icon apple-touch-icon.png to your web app’s root directory will provide iPhones with a nice custom icon when users add an app to their home screens (iPhone will take care of the rounded corners and glossy visual effect) and you can make an iPhone app go full screen when clicked from it’s home screen icon by adding . At this point, the app has it's own icon and runs full screen - the user doesn't know it's web based.
And if you do want to go native but don't want to abandon web standards, most native APIs provide the ability to develop native clients based on HTML/CSS/JS using a simple wrapper, such as the UIWebView in Objective-C. PhoneGap is an excellent cross-platform framework enabling standards-based web development practices to be deployed on iPhone, Android, and Blackberry.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
There's a lot of mobile platforms out there at the moment; iPhone, Android, WebOS, Symbian. If creating a startup for mobile development (i.e. as a commercial endeavour, not a hobby), which mobile platform is worth focusing on?
First, ignore technology to start and instead look at the business model for each platform. Ask if the platform itself has a reliable means of producing revenue long term. If so, then ask if the platform presents a business model that allows a developer to make money. If your not sure about such stuff ask someone with business experience.Beyond an initial flurry of interest, nifty tech can't sustain a platform if the economic underpinnings are not there. Even if a platform prospers, it doesn't mean that small developers will.
As near as I can tell, Android isn't actually a platform but more like a loose standard. Each phone vendor can customize it to a high degree so there doesn't seem to be a means by which you can write a single app and know it will run on all Android phones. That will cause major market fragmentation so even if Android takes off big time that doesn't mean that every developer, especially small developers, will be able to sell to the entire installed base.
Long term, open platforms (like contemporary PCs) present major problems for small developers. There is no intellectual property protection so developers who don't have large institutional customers they can sue can't prevent piracy. Security will become a major issues as black hats target people's phones. There will be a huge number of crappy or actually fraudulent apps cranked out that make end users leery of buying software from a vendor they don't recognize. This means small developers will have a hard time breaking into the market.
One of my professors in college told me something that has proven true in my 20+ years in the computer industry: The major strength of every design is also its critical weakness and vice versa. The very things that make open platforms attractive to developers and customers are also the same things that will cause them major problems. The very things that turn developers off about closed platforms are the things that provide the greatest benefit to developers long term. Having a closed platform's vendor vet every app slows down acceptance and limits choice but improves overall quality, security and consumer trust. And so on...
Career wise, there is a difference in paths between running your own business and learning an API so that others will hire you. In the former, you should develop for the platform that has the best business model and the one you would most like to use as a consumer. For the latter, you should develop for the platform with the most buzz. Even if it flops, no one will find it odd that experience is on your resume. Just rough rules of thumb.
I've written and launched two mobile apps on the iphone over the last year and both have had success in economic terms. One app is free and tied to a web service and it has a significant impact on the popularity and number of users for the web service. The second app is a paid app - and I can tell you that it is producing some actual revenue, enough that if I was a solo developer it'd be paying my bills.
That said I think that if you're launching a company for mobile products you don't want to put all your eggs in one basket. So either support multiple platforms or aim to have multiple products on your main platform.
I think there is big potential in Android but at the moment it is totally unproven as a platform where you can actually make money (please point out some info on this if you have any I am really curious about the economic potential of Android).
Blackberry is also interesting since pretty much everyone I know who's under 25 has one, but it is a platform where selling apps doesn't seem to have caught on that well. I've discussed it with some heavy blackberry users and apps are not something they really care that much about. So you'd want to try to find out some numbers regarding Blackberry app sales.
In the end it depends on your target market/product.
Are you building an enterprise targeted mobile app? - Build for Blackberry first and perhaps iPhone next.
Do you want to launch one consumer focused mobile app with a large feature set and perhaps some web service integration? - target a few platforms and make it available to as many users as possible.
Are you trying to build a series of small purpose built apps? - Definitely start with iPhone and get some revenue first.
My 2 cents.
Not Iphone.
Because of Apple and this strange policy of application approuval. You could not afford to close your entreprise only because apple has decided that your application is "not ok"
Edit : For sure, the AppStore has a huge potential client base. But it's also the only "mobile market place" from where you can be removed.
If you are having a hard time deciding, why not just develop for all of them at the same time!
PhoneGap is a utility that lets you build apps that run on several different platforms. It's great, and the guys at Nitobi are very willing to help you out.
I suspect at the moment you would get the largest pool of potential customers if you developed for the IPhone. Apple do have some issues with their control freakery but, hey, people use their AppStore.
Personally I am going to develop for Android because I absolutely love the design of their OS for mobile systems. Just brilliant. I also suspect that Android will increase in market share rapidly over the next few years. It's also Java instead of objective C so I would think easier to port to other environments as required. I'm doing development for fun though so if I make no money then who cares. If you actually need to make the development pay for itself then I guess IPhone is probably the way to go while keeping a close eye on Android.
The thing about the AppStore for the IPhone to keep in mind is that, not only do people use it, they also PAY for things from it. Android still doesn't let you sell to any country so even if they were to technically have more users - those users might not be able to pay for your stuff even if they wanted to. This is being worked on by google and will change but it does limit the amount of money your app could currently make.
It depends on your target audience. Business users will most likely use BlackBerrys or Windows Mobile (at least in my experience). Consumers (at least those willing to pay for software) will more likely use IPhones.
It depends on the application somewhat, but if you are serious about a startup it makes the most sense to start with the iPhone. The frameworks allow for the most "wow" factor with products, and there is simply a huge lead in number of units, and number of users used to running many different applications.
You may also want to consider other platforms (my vote for second to go after would be Android, and then Palm in third although that depends heavily on what your application is).
But something to consider is, you may want to start by doing one platform really well and if your application idea is well received, branch out. It's a lot of effort to develop for multiple platforms and each platform has various unique features you want to spend time taking full advantage of. I would also advise against using any of the cross-platform frameworks for the same reason, because when you target all you cannot really target one.
Depending on what you want to do, I think you should look at web toolkits. Web apps, a.k.a. Widgets run natively on Symbian, and through Opera on many other platforms. It should be simple to port to Palm WebOS if that catches on.
You can't do everything in a Widget, but you'd be surprised what is possible.
Based on my limited experience with seeing what devices are used on subways, trains, in airports, etc - I'd suggest either Blackberry or iPhone.
But more importantly, pick a platform you like and are excited about.
If you are not enthusiastic about the platform and you are doing it solely for the money then it will show. you might as well just make hamburgers or sell lotto and cigarettes.
Take this with a pinch of salt but this pie chart seems to suggest that Symbian is the most widely used:
http://en.wikipedia.org/wiki/Smartphone
Or Java ?
Java is used on Blackberry's and will run on Symbian.
I wouldn't have said this 6 months ago. But I'd go with Android.
It'll be significantly more work porting in the long run. As more and more screens sizes and device profiles are coming out, but I think it's got the weakest developer market with the highest long-term potential earning power. The iPhone market is flooded, so, even if you get your app published to their catalogue, it's still almost impossible to get any kind of exposure.
Android, on the other hand, has huge growth potential and a pretty poorly followed market-place.
Verizon's massive push on the 'Droid' should open that particular device to a huge marketplace. It remains to be seen, however, if and how they'll allow 3rd parties to publish apps to their catalog.
Depending on your timeline, you might also consider Flash as a cross-platform option. Here's a list of heavy-hitter companies working to make mobile Flash happen in the near future (includes Google, RIM, Nokia, Sony Ericcson, Palm, Motorola, Samsung, etc.):
http://www.openscreenproject.org/partners/current_partners.html
...a video of some of their CEOs...
http://www.openscreenproject.org/about/
...and how to apply for some of the $10MM that Adobe's seeding into the market:
http://www.openscreenproject.org/developers/get_started.html
In summary, I'd suggest going for a cross-platform approach.
Symbian has by far the biggest number of users and has the largest choice for programming languages.
Symbian and Maemo will be running Qt in the near future, as well as supporting open python, open C, java etc etc etc.... (they also both have the Qt libraries available now)
I wouldn't put too many eggs in the iPhone basket. Your application would have to be monumentally good to be found and paid for by a significant number of people in the 100,000 items in their app store.
Android, don't really know anything about it. It seems like it could be a popular platform, its at least a real multi-tasking environment (unlike iPhone from app dev point of view).
Palm Web OS is insignificant at this time.
Perhaps the best solution in fact is to make your application web-based then you can just develop small apps which hook in to the web service?
Mono sounds interesting to me
Mono on Android - androidMono
Mono on Iphone
Like phonegap there is appcelerator titanium