I am pretty clear about the fact that I build software to leverage hardware devices that they work with the iPhone thru EAAccessory and bros.
What I am not clear where do I get the hardware specifications if I want to connect an Arduino project with the iPhone?
Everything you need can be found here
http://developer.apple.com/iphone/program/accessories/
The process is fairly straightforward.
-t
You join the Made for iPod and Works with iPhone Licensing Program - it involves a few NDAs and legal documents, then they give you the specifications for connecting with and communicating through the i/o port or bluetooth.
Here's a blog post detailing what one person went through to get into this program and gain access to the documentation:
Part 1:
http://www.stackoverthrow.com/?p=97
Part 2:
http://www.stackoverthrow.com/?p=100
It looks like there's no extra fee (above the usual $99 developer program fee) but there's a lot of back and forth paperwork, including faxes, mail, etc which stretched the process out for him to nearly 2.5 months.
He hasn't given much of the nitty-gritty details, so there may be more to it (ie, you may have to disclose your intended application, and if they don't like it they may turn you down) but it gives the process from a recent program applicant. Would be nice if it changed so it was all online, but I'm thinking they may still require all the paperwork.
Related
I am writing an iPhone app, and I have a remote server that will deliver content. I would like to have my app poll the server once per day to see if there is new content, even if it's not running or in the background. I would also like to do this without setting up an APNS. Any advice?
You can't do that, either when your 'not' running or if you are running in the background. The best you could do is to download once per day when your app is first run / pushed to the foreground.
You could use remote notifications to "prompt" the user to bring the app to the foreground so that it could download something?
With the current apple IOS guidelines, that is about the best you can do.
I read that you are trying to avoid using APNS, but I am wondering if you are trying to avoid it for the right reasons, especially when it is designed to efficiently solve the scenario you are describing. I've seen many developers seek alternative solutions to APNS simply because the technology appeared to be complex to use after looking at Apple's documentation. The online documentation does go into a lot of details, right down to the binary protocol level.
But just to be sure you know, there are open-source libraries whose only purpose is to shield you from all these technical details. Some libraries are more complex than others, but some are remarkably user-friendly. If you have not done so already, you might like to take a look at JavaPNS and other similar projects.
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.
I want to build an app that can communicate to some external third party hardware. I come to know that External Accessory framework can help me out in that, but I have few confusions……
Do I need to register ‘Made For iPod’ program before I start?
Do I need the third party hardware before I start, or I can start without hardware?
Is there any alternative to test the app, if the hardware is not currently available?
You could do that. But they don't approve everyone who registers like in the iOS program. It takes (in my experience) a lot of time and they have requirements that not everybody can met. You don't need to apply if the hardware is ready. The MFI program is for hardware developers. If you don't make hardware I wouldn't even try to get into MFI. It's a waste of time and money.
If you write an official app for the accessory, the company that makes it should give you a prototype so you can get started ASAP.
I would highly suggest to get the hardware. And if this is the first accessory project for you and the company then I would consider to go there and start writing the basic code on site, where you can get your hands on the developer.
The communication works with streams. I never tried it but I think you could write the whole protocol specific communication with network connections and then replace the networking stuff with the EASession once you have the hardware.
If you want to test the External Accessory framework you should have a look at EADemo. I never tried (and I don't have a accessory near me to test) but I think this should work with all accessories. But in my opinion everything EA Framework related is the easy part of the whole process.
Summary: Get the hardware. If you'll get the hardware in two weeks do the User Interface part now. If you can't get your hands on the accessory within two weeks you should beg for a prototype.
Regarding your comment to the other question: Test equipment is available when you are a member of MfI.
If you want legitimately produce and certify your third party hardware, you will need to apply for 'Made For iPod’ program. You will get and API and documentation to do that.
Unfortunately your chances to be approved are very low.
For the sake of coding itself, I know that I don't need to buy iPhone as there's pretty good emulator.
However, as I will develop iPhone apps for clients (will not have direct contacts to clients) via freelancers sites, do you think that I might get rejected (not chosen) by the contractor because I don't have iPhone at home?
Do contractors accept this way of working:
I develop the app, test it in the emulator and send it to them
They test it in iPhone and send me the list of the bugs
I fix the bugs and send them the app back
They find new bugs and...
Yes, or at least an iPod Touch.
To clarify:
Yes. You really need one. Debugging the kind of errors that cause it not to open on the device at all, for example, can be mind-numbingly tedious if you don't have the device handy.
For most purposes, of course, an iPod Touch should do just fine, but the crux of the matter is that the testers can only test what they see; only the developer can actually test crucial stuff, most of the time.
So to repeat. Yes, you'll need a device. A thousand times yes.
Your client may have something of an issue paying money for software that was never tested on actual hardware. No matter how good an emulator is, you should always try the software on the real machine your program will be running on. The emulator will simulate the way the API responds etc, but you could be blindsided by things such as interference from other running applications, subtle timing bugs, interaction between different versions of the firmware or hardware, etc.
In short, I don't think there is a legal reason you have to test on a real iPhone, but from a Q/C point of view, I think there is no question you need the real hardware to run it on.
Paying customers generally dislike being treated as a beta tester.
I don't think that you won't get the clients - but I do think its a terrible idea not to have a device to test on.
There are many things that won't work properly in the simulator. For instance you can't simulate a camera function, you can't simulate GPS (properly - it always sets you at the apple HQ), you can't simulate sound recording, or test with a real contact address book or a real set up. You can't test whether there is an internet connection or if there are any iphone specific bugs.
On the other side of the coin there are loads of things that will work in the iphone simulator that won't work on the device itself. For instance NSXML and such won't work on an iphone, but WILL work in the simulator.
If you can get hold of one of the new ipod touches they do pretty much most things you will need, and you don't have to get into a data plan or anything. I would suggest AT LEAST getting one of those. You can't make apps if you can't test them properly.
Other things:
In app purchases - #Stephen Darlington
Whenever working for clients, the clients do not pay you for having an iphone or not... or being able to test it on a actual iPhone. The clients pay you for the product you deliver. They expect it to work on the device.
My recommendation is to get yourself an iPhone 3, 3gs and 4 if you want the best results. But, if money is a object here... try developing minor projects which are reliable in the simulator. AND ask friends/family which do have iPhones to test it for you on their device. Its better to ask mates to do this, then ask the client, this way you have a better comunication with your client, your client has more faith in you and... well lets face it, it is the developers responsibility to deliver quality code. Right?
There are some tests you cannot perform in the emulator.
And I am not sure contractors will like this ping-pong test approach (somebody will get tired after couple passes).
You can get an old second-gen iPod touch at a very good price since there are many people who would like to get rid of it. And Apple advices to test apps on older hardware to achieve the best performance. So you'd better get something 'hard' to play with.
Another aspect is performance. The simulator (running on a powerful Mac) will be much faster than a device. This was a huge difference with the original first iPhone.
As an alternative to the iPod: look for a cheap original iPhone on eBay or so. But remember that this will not run iOS4.
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.