Tag Info

Hot answers tagged

28

There are several advantages of creating a native app: Better control over the UI experience - the mobile web developer would either need to recreate or use frameworks that emulate native UI artifacts Access to platform APIs that might not be available to web apps - this is currently the biggest advantage for native apps Potentially lower network usage at ...


23

In layman's words: Not all users use all of a company's apps Different users have different needs Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.) Having those apps separate makes it possible to be updated separately and, most importantly, sold separately. The fact that ...


14

I'm a mobile developer who has spent a great deal of time considering this issue. Why do you ask? Most likely, you hope to reduce app development costs by: Using existing HTML5/Javascript development skills Targetting multiple platforms without writing multiple apps from scratch Not having to maintain multiple codebases in the future Reasons may also ...


14

I think that you can only lose by choosing not to communicate. If you don't plan to implement the feature now, at least suggest users that it is not in the current plan to implement, but might be considered in the future. This would not let users think that it's a feature they can expect soon and will send a message that you are not planning on it either. ...


12

It worth it if measurements say it worth it. For mobile device as well as supercomputers. EDIT: Little off topic, but about your exemple. If the event is triggerered too many times, then you have a conception problem, and solving that conception problem is the real deal. Not make it less visible by microoptimizing. You can perform a test in the callback ...


10

Probably the most important reason is mind share. What almost every internet company wants is for your mind to be tuned in to their product. And one way to build mind share is to make access to the content as easy as possible. How do the two delivery mechanisms compare? Mobile Web Application: User Thinks "I want to go to Facebook" User clicks on ...


10

You need a Service Oriented Architecture. Because you are sharing data across all those platforms, Web Services.. Basically rather that calling a "function" you make an HTTP request to a URL, parameters are passed in via the query string or Http header. XML or JSON is returned. Read up on it. Thing is, your app need to be online at all times...


10

Put together a stock "thank you for your interest" letter that covers the possibilities of a) features you will NEVER implement even if I show up on your doorstep with a bag of gold, b) features you don't PLAN to implement but maybe, and c) features you'd like to implement but can't right now. Send that. Because you ALMOST never know when you might find ...


9

To really give an exact answer to your question: Yes. Although JQueryMobile is meant for web applications (as pointed out by Yannis Rizos), you can use Phonegap to create native applications with JQuerymobile. What Phonegap does, is create a native app with a webkit browser embedded. So it still is kind of a web application, but also kind of a native app, ...


9

jQuery Mobile is: A unified, HTML5-based user interface system for all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation. Its use is to provide a consistent experience across mobile devices UI for web applications. Web applications are applications that are accessible via a web browser through the Internet. Some ...


9

They might want to see the schema so that they can replicate it on the mobile device. That will save them some work. Additionally, seeing the schema might prevent them from making wrong assumptions about how their data should be structured based on potentially-incomplete information about the database. However, they should really come up with their own ...


8

Smart phones are different from normal PCs. The screen size and touchscreen make traditional webpages much more difficult to use. By creating an app for phones a better experience can be delivered to the user. Creating an app also allows for more information to be gathered on number of active users, and information about users. This provides ways to better ...


8

PhoneGap is client-side, so scalability is fairly irrelevant - you always have one user on one device. As for app complexity, you can do a lot with HTML5 and JavaScript - There's no IE on iPhone, which makes everything a lot easier. There may be some things that can't be done from html or require the performance of native code, but PhoneGap has a fairly ...


8

A QR Code has a version range from 1 to 40. This information tells about how much data is stored within it. Version 40 has 177 rows and 177 columns (in some decimation called 'modules') for 31,329 pixels. It should be immediately clear at this point that this is the hypothetical maximum that doesn't take into account the error correcting or any of the ...


7

It sounds like the best way to go about this is to go to the manufacturer's developer page, or the page for the operating system. Here are some of the developer pages I was able to find: Palm Developers Page bada Developers Page iOS Dev Center Android Developers Page MeeGo Developers Page HTC Developer Center Motorola Developer Network Sony Ericsson ...


7

Since you are talking about mobile applications, there is one specific thing that you must consider: the time to type. Here's a screenshot of an emulator of Windows Mobile. By default, the TLD is .com. It means that to access example.com, I have to type eight characters. To access example.net, I have to hold .com button until I see the .com, .org, .edu ...


7

You Can't. You can never verify an entity, any entity, be it a person, hardware client or software client. You can only verify that what they are telling you is correct, then assume honesty. For example, how does Google know it is I'm logging into my Gmail account? They simply ask me for a user name and password, verify that, then assume honesty because ...


7

To me, the table on the website you mentioned has a somewhat-naïve representation of these differences. It seems to focus on pushing a native app as the best possible solution because of "browsing speed" and access to device functionality, but this may not always be what you actually want to achieve. They haven't taken into consideration other factors which ...


7

Ideally, you should use such requests as an opportunity to help you and users better understand the application. If you think of it, the very reasons why you prefer to ignore these requests are quite important information and you'd rather have them stored and documented than buried and forgotten deep down in your mind. If a request is ignored because you ...


6

Users expect a mobile app to perform a single task, or a small set of very related tasks. The mobile platforms that you mention started particularly as phone OS's. Typically users performs many short tasks on their smartphone throughout the day. This is totally different from desktop computers. This short bursted usage pattern has lead to the design of a ...


5

I haven't actually tested them, but have made some research and I found that there are some more like Phonegap, you should look at Titanium from Appcelerator or if you have a game oriented idea you should look into Corona from AnscaMobile. I've found at least one success history of a boy who used Corona for a mobile app. If you want to get some nice ...


5

Phonegap only provides the framework for shared code on different platforms. In order to build the app for each platform you have to use the native toolsets so; Visual Studio for WinPhone, XCode for iOS, Eclipse w/ Android SDK for Android, etc. You can reuse all your PhoneGap code but you need to create projects on each platform to build and submit the apps ...


5

Am I right? Is there something I've missed? You're right. There may or may not be something you've missed in the API, but there's nothing peculiar about writing a mobile app that would require the developers to know what your database schema looks like. On the contrary, the more they rely on your public API and the less they rely on private ...


5

Both Android and iOS support some form of push notifications. You should absolutely take advantage of those to deliver your reset messages rather than polling. Running radios unnecessarily can be a huge battery drain, and shifting the responsibility for delivering the reset message to the operating system will be a significant improvement. For Android, you ...


5

I'm currently working on a mobile/desktop/distributed app with exactly the same requirements and issues. First of all, these requirements are not inherent to mobile apps per se, but to any disconnected/distributed client-server transactions (parallel programming, multithreading, you get the point). As such they are, of course, typical issues to address in ...


5

You pass username/password to the login method of your RESTful API and it returns access-token. That access token is just some unique (for the system) string. Device stores (persists) that access-token. Each time you send RESTful request to the server you put that access-token in header of HTTP request. Server finds the user by access-token and on success ...


5

Native applications use Objective C or Java. Web applications use HTML5, CSS3, and Javascript, running in a browser. Native applications may have to be written more than once, to satisfy the native platform's specific demands, such as programming language. Web applications may have limited access to the underlying native platform, and may not perform as ...


4

There are few problems with unit-testing mobile apps. emulators do not behave exactly like real hardware, there are ocasional incompatibilities; some emulators do not throttle the CPU power to emulate limited CPU power of mobile; some emulators do not throttle the network to emulate limited throughput and latency of 3G connection; in case of Android ...


4

The most common gotcha in mobile apps is thinking that somehow they're different from immobile apps. The next most common gotcha in all apps (mobile and immobile) is spending time looking for reasons not to write tests. The time spent researching the topic could have been spent writing tests.


4

Biggest benefit of Smartphone application verses web based application is offline functionality. Depending on how the app is written you can still get work done regardless of web connection. If a Smartphone app needs to report events to a web service, it can always queue them up, then sync the next time the app has access to the web. There have been many ...



Only top voted, non community-wiki answers of a minimum length are eligible