Related
Every now and then "memory cleaner" apps bubble to the top of the download charts on the iOS AppStore, yet I am always puzzled: How can these apps figure out how much memory is used when they are sandboxed and can't access any memory outside of their process?
I'm not an expert in memory allocation on C, so maybe the solution is obvious and I just don't know it but I am curious as to how this works/could work.
Obviously the second question is how do they clean the memory once they have the count, I assume they just allocate a ton of heavy objects (eg. images) and thus force the OS to shut down other processes. Yet maybe there is a smarter way?
Note, I am not talking about Cydia here, these apps are available on the regular AppStore and work on non-cracked devices with the official consent from Apple. As an example, here is the current top seller: http://iputzfrau.professional-apps.at/
The Mach/BSD host_statistics and sysctl functions are available on iOS, and they provide access to system statistics such as the amount of physical RAM, processor speed and, indeed, the amount of free RAM available. To get the latter, you'll want to call host_statistics with HOST_VM_INFO, and look at free_count in the structure it fills out for you. Note that this value isn't necessarily useful for any real purpose. You probably don't need it unless you want to write yet another one of these scammy apps.
Low-level functions in the C/UNIX/Mach/BSD layer are generally available for use in iOS apps, although these APIs typically aren't described in the SDK documentation. Look at the headers in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/ and refer to the Mac OS man pages, C/UNIX standard documents or the Mac SDKs for more details about them.
These apps, as with the "track any cell phone" apps that have "for entertainment purposes only" buried in line 30,239 of the description, are scams. It's exceedingly frustrating that Apple lets them through the review process.
You're right -- there's no public API that would enable an app like the one you linked to do what it claims to do.
This would be an excellent question to pose to Apple, or at least post in the Apple developer forums. You could also report a bug, probably the most effective way to register a complaint without knocking yourself out.
We've reviewed XXX and determined that we cannot post this version of your iPhone application to the App Store because it provides to the user potentially inaccurate diagnostic functionality for iPhone OS devices. There is currently no publicly available infrastructure to support diagnostic analysis. This may result in your app reporting potentially inaccurate information which could lead to user confusion.
Has anyone encountered this rejection reason? Can I just add the disclaimer in the app in order to get approved? Has anyone tried this? Or any other trick?
Given that it is impossible for an app to actually test for dead pixels, I'm going to say Apple is on solid ground here. Any such test would rely on a human actively observing the pixels so it wouldn't be an actual measurable diagnostic.
The situation with the App Store isn't like the situation with software that isn't sold through Apple. Given that Apple test and approves apps for basic functionality before allowing them in the App Store, letting through an App that claims to provide diagnostic information about hardware is tantamount to Apple stating that app does provide hardware diagnostic information. However, the API does not provide such information and Apple is not going to hinge their warranty payouts on some, for example, 16 year old kid's idea of what makes an accurate diagnostic tool.
Apple is imagining this conversation:
"Hello Apple? I have dead pixels on
my device. How do I know? I ran an app
that says I do. Hey! You approved the
app for the App Store so that's just
like saying it does detect dead
pixels! If it didn't you shouldn't
have accepted it!"
... and Apple's lawyer gets a new Porsch.
I ran into issues with 3rd party diagnostic software back when I was at Apple. One of the big headaches is that the 3rd party diagnostics offered no protection against false positives. Customers and Apple would spend a lot of money chasing false positives and the diagnostic provider would just shrug. It wasn't their problem and it didn't cost them any money.
Official diagnostic software has to be rigorously tested as false positives cost everyone a lot of time and money. Apple is not going to make a 3rd party tool quasi-official by adding it to the App Store.
You can easily add a "dead pixel" remedy. I remember the old PSPs used to have a quick color flash that fixed pixels well. Red, yellow, etc. Seizure status.
The probability of SEEING a dead pixel on the retina display is probably going to be very difficult if not impossible by the naked eye.
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
Something I've noticed about every iPhone app I've tried is that they all have places where they seem very slow and unresponsive. It's true of the games, the free apps, the pricy, popular, "professional" apps, and even a couple of Apple's built-in apps. They all seem to have places where they take many seconds or even a minute to respond to screen touches; bog down and show a spinning beachball for seconds at a time; "queue up" input so that a button press appears to ignored only to actually do something ten seconds later like a poorly made DVR; and lock up for so long that the OS watchdog just kills them.
Because these perf issues are so widespread it seems to me that there must be some common performance pitfalls some system gotchas that are coming up over and over again for lots of different people. I'm not an iPhone developer myself, so I'm canvassing the community's opinions:
What are the most common performance mistakes on the iPhone?
Or, what human factors of iPhone development make it too easy to ship with poor performance?
I think that the performance issues are a matter of perception. Apple has employed animation throughout every aspect of the iPhone's interface, which produces the impression of a smooth, responsive device. The slowdowns you refer to appear much worse than they might be because they stand out from the otherwise fluid interface. If you compare the total execution times of these tasks to similar applications on other mobile devices, I'd guess that the iPhone implementations would still come out near the top.
There's always room for improvement, though, and I'd expect that many of the tricks people have learned in the last year will lead to faster, more responsive applications. Even the development tools themselves are advancing, and that should make it easier to diagnose and deal with performance bottleneck. I know I keep learning new tricks every week for squeezing a little more out of the CPU, GPU, or onboard memory.
I'm still surprised by how quickly people have shifted their expectations as to what handheld devices can do. I'm the author of an open source application called Molecules, which does 3-D molecular modeling on the iPhone. A little over ten years ago, these types of renderings were being done on dedicated SGI Irix workstations. A few weeks after the launch of the App Store, I started receiving emails from people complaining that the application was a little jerky when they tried to manipulate molecules with over 20,000 atoms in their structure. In a very short time, people went from treating these devices like phones and music players to viewing them as portable computers.
Memory management is a bit of a beast.
But I think the biggest problem is this: How long can you afford to polish a product that will sell for 99 cents and compete with tens of thousands of other apps and has unknown revenue potential in a rapidly changing market?
The iPhone is a GREAT little device, but the competition for mindshare is fierce and expensive.
As mentioned before the ratio of profit/time spent in development would explain it.
More technically, I would say that the lag you see is created on startup when apps are either getting data over network or calling home to check for updates and so on. Additionaly it may be created with initializing application like loading large amounts of data from database/files, loading gui components and images, drawing and so on.
Similar to memory management this all can be solved by designing operations to run in background, lazy loading and so on but that requires more time, time is money, you don't get much for 99C app which may or may not sell at all.
It is interesting that so many times it is pointed out in professional articles (no ref...) that we should not care anymore about memory and speed because desktops are getting faster with more memory. What people tend to forget is that at the same we're trying to squeeze more power from smaller and smaller devices that are running with smaller resources.
Most web pages for example are nowadays designed to load huge amounts of animations and images and, unlike some, are not tweaked at all for performance but do just okay on desktops. Those web pages have no chance of loading on mobile device. The same goes for applications, designing a fat big framework (or gui widget library) for desktop will make it ultra difficult to port the functionality to sleek mobile device be it iphone, some fruit berry and what not.
As in other things in life, you get what you paid for.
My 99C.
I think the biggest issue is that it's impossible to determine the speed of an app without actually running it on the device. Developers perform most of the basic app testing in the iPhone Simulator (which can run up to 1000x times as fast in my experience). Some operations that take a split second in the simulator might require a progress indicator on the phone, and by the time you realize, it would require a lot of effort to go back and add (and in some cases thread) the operation in question. As Noshredna pointed out, it's generally a 99c app.
The iPhone's processor is also just fundamentally limiting. I've seen several nice looking apps that try to do very impressive things without accepting the constraints of the platform.
This is sort of a side note, and I don't want to start the mobile platform wars, but I've found that iPhone Apps are generally more responsive than Android apps...
Well, because maybe you deleated the app and install again because something wrong happens to it, so it must took awhile, it took me about 2 or 3 days to get full loaded so be patient, it will come eventually. Also maybe your iphone doesn't have any more spaces for your app, or your app is quite heavy, try and delete other apps so it will have rooms.
I was trying to compare the three above mentioned platforms and what considerations one needs to think about when programming in order to create some kind of code base that could run on all three.
This is what I have collected for the iPhone - it would be great if somebody else could write something similar for the other two.
Only one application can run at any
given time. i.e. that is why the
SQLLite database is loaded as a file
into the app instead of as
traditionally having some kind of
server to connect to.
Only one fixed size window 480x320
pixels
Runs in a sandbox, when the app is
deployed a sandbox is created
"around" the app, the app can only
read/write files from within that
area. Also low-level access to the
phone is restricted.
Since a program can be stopped at
any time (see point 1) this needs to
be considered when designing the
app, at any time must the app be
able to write its current state to
disk so that it can resume later. If
this takes longer than five seconds
the app will be aborted.
128MB RAM, about half of that 64MB
is available to the app. There is
typicall 4GB storage (depends on
model), no virtual memory, if memory
is running out the app may be
aborted.
Edit: just to be clear, I am not after which platform/os is best for the developer, I am just interested in spec. comparison to know what can be expected if one has three target platforms and using native language for each (not web apps), what the memory and other considerations are.
Edit: removed language as its assumed that native language for the platform will be used.
There is an excellent article on Codeproject which would be of benefit to your question. Head on over here to read it.
Hope this helps,
Best regards,
Tom.
For Windows Mobile I want to add:
Windows Mobile in comparison to iPhone allows multiple applications to run at same time.
It comes with variable screen sizes and has different sdks (
Windows Mobile Professional for 'Windows Phones' (smartphones) with touchscreens and
Windows Mobile Standard for 'Windows Phones' with regular screens)
The framework which is generally used is .Net Compact Framework besides some people also prefer open-net which is a open source framework.
Unlike in iPhone, Windows Mobile has no private api's which means it gives more power to developers.
The memory size allowed for a program is 32 mb
You do not need a developer license for developing and shipping applications on windows mobile although windows mobile itself prompts you to avoid installing apllications which are from unknown publishers.( which is more interesting unlike in iPhone you need to have a license while you only want to debug your applcation on your device(not for the jailbroken devices.))
And for some bad things about windows mobile, see this link.
Thanks,
Madhup
I feel like the final list will be of little use, as all data points collected will differ substantially in content apart from your last one. Some corrections to your iPhone list:
1) Local databases such as SQLLite are"not traditionally" implemented as a server on other mobile platforms either (they also use various file-oriented DB's).
2) Very soon that single fixed size assumption may well be inaccurate.
3) The App is in a sandbox but can write to some areas outside of the sandbox via API calls (for instance, photo library or address book).
5) That number varies between 3Gs and 3G/2G/Touch (the older models have half the memory)
6) Monotouch is available, but I'm not sure there's anything that far along for Java based iPhone development. There's also a Flash compiler from Adobe.
Basically if you are thinking cross platform, memory/screen size/system access/common databases will all differ - so the whole thing boils down to language AND LIBRARIES. And that is where you really have an issue with a cross-platform approach, because the libraries are very different per system... in the end you MIGHT be able to share data structures and some pure data processing code across the platform binaries, with very different GUI code for each system. But is it really worth it to constrain the development of each client?
On a side-note Blackberry is Java-based, so it presents yet another hurdle for such an attempt.
If you really want to see what cross platform ends up looking like, take a look at the codebase for Waze - a cross-platform open source navigation app:
http://www.waze.com/wiki/index.php/Source_code
Client source for iPhone and Windows Mobile lives there.