Hot answers tagged

47

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 ...


39

This article sheds some light on the situation. The most pertinent link within that article is this. So you've got a massive install base with lots of programmers who know the language and it's widely taught at universities. C++ was dropped from my school's curriculum, Java is still here. Java has Java ME which has a massive install base on other cellphones. ...


31

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 ...


31

I'm sure you're comfortable with dealing with user logins, and with communications over SSL, so I'm going to focus on what I think it the more interesting part of the question: how to ensure that your read-only actions - which do not require the user to be authenticated - are only accepted from your own client apps? Before anything else, there is the ...


29

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 ...


27

The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs. This is your problem right here. You have limited your resources to (I'm assuming) the models in your database. As such it is taking ages to load all these resources because your server has no concept of resources that don't have a ...


23

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 ...


22

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 ...


18

I'll hazard a guess that Google choose Java for familiarity, if nothing else. Many of Google's projects revolve at least concepts of Java schematics (GWT for example). In addition, it's a language widely taught in technical schools (unlike say, Javascript (which Android also zealously supports)). Java's certainly not the best language for a mobile device in ...


17

For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails. The designers of a smart phone OS must ensure that no application can interfere with these primary functions. The other constraint of mobile is battery life, any app which "spins" in the background it will consume current and ...


17

The answer greatly depends upon the legal jurisdiction you live within. But let's take the easy considerations first. As brought up in the comments: what happens when your device breaks or your device injects malware into your team's development stream? So then you need to ask: Who pays to fix your device? Who is responsible to replace your device if ...


16

ARM concentrated on power consumption from the beginning. This has given them a huge advantage in almost anything that's battery powered. The popularity of x86 is primarily for historic reasons -- it's been there forever, and it's been good enough that most of the market has had little reason to switch to anything else.


16

To understand delegates, you have to understand protocols. A protocol is like a service contract. When an object (most often a UIViewController subclass, but not always) signs that contract, it is saying "I am interested in providing logic to back the message you send me". This is similar to NSNotificationCenter in regards to signing up for a level of ...


15

To anyone interested, on Android you CAN verify that the request you have gotten was sent from your app. In short, when you upload your app to google you sign it, with a unique key that known only to you (and google). The verification process goes(ish) like this: your app goes to google and ask for auth token your app sends the token securely to your ...


14

There are several way how to implement authentication in RESTful context, and it is more safe to send only tokens instead of login/password: you could easy make tokens to be invalid by timeout or by some other criteria, and ask user to re-authenticate. For example authentication REST requests using HMAC. In this approach, client will have public and secret ...


14

Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other? The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message ...


13

If something you can take with you, but not really for using on the move, take a look at Raspberry Pi. You can use it on the move with a USB power pack designed for giving your cellphone extra battery life, but you'll also need to bring some sort of screen / output device with you, and maybe a USB keyboard or something.


13

The key attributes of a RESTful applications are: All communication is via http GET,POST,PUT,DELETE AND all items are addressed via a standard URL of the form http://your.site.com/salesapp/salesperson/0000001/details i.e. only a pure URL with no parameters etc. the URL identifies the thing the GET,POST,PUT,DELETE identifies what you want to do to it. The ...


13

For starters, the vast majority of apps, of the million out there, do not sell well, whether open or closed source. So don't expect any app to sell well unless it is a stand-out app and well marketed. For iOS apps, someone would need to have paid Apple $99/annum for an iOS Developer program enrollment, plus have a Mac, in order to be able to download your ...


13

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...


13

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 ...


12

It's worth it if measurements say it's worth it. For mobile device as well as supercomputers. EDIT: Little off topic, but about your example. If the event is triggered 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 ...


12

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, ...


11

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 ...


11

The poster boy for HTML5 apps, LinkedIn went native early 2013. In the interview in VentureBeat they explain why. I think this is the part most relevant to your question: Prasad said performance issues weren’t causing crashes or making the app run slowly. What he did say shows that HTML5 for the mobile web still has a bright future — but only if ...


11

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 ...


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

First, you mentioned both an API and a database (MySQL). I very much recommend that you use an API and don't try to communicate directly between the databases. That latter route will not scale well at all. One good starting point you should consider is using Apache CouchDB. It is schema-less, based on HTTP and JSON, and has a very good replication mechanism....


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