I have implemented one application in which i want to implement pedometer functionality.Is it possible to implement pedometer?Please give me idea.
This is certainly possible, and I believe has been done. The main drawback is that since the iPhone does not permit 3rd party background tasks, your app will have to be open to collect pedometer data.
The simplest way to do this would be to setup an Accelerometer listener, and watch for 'step events'. You'd have to do some experimentation to determine the type and size-range of these, but that wouldn't be too difficult.
Expanding on Ben's answer: you might want to write an app (or use an existing one) that continuously records the data from the accelerometer and shows a graph thereof, then have that app running while you and a few different people walk around with the device in their pocket. That should give you an idea of the patterns of acceleration you need to be looking for, as well as the variation possible in peoples' stride lengths, gaits, etc.
Related
I'm programming an app on ios with xcode and I after a lot of work I found out that the functionality is really dependant on the accuracy of the methods calls.
Calling them one line after the other in the code doesn't help, they're still called at up tp 150 ms difference after each other.
So I need to make two methods run at the minimal time difference, hence "at the same time".
These two tasks I'm performing are actually audio and video ones so I understand it might include also in-process latency and delays, so I was wondering maybe you guys would have any isight on how to sync an audio task and a video task so that they start running together, with a very tiny time gap.
I tried using dispatch queues and stuff like that, but they don't work.
I'll be happy to elaborate if I wasn't clear enough.
Thanks!
You can't make an interrupt driven, multi-tasking OS behave like a realtime OS.
It just doesn't work that way.
You'll need to use the various multimedia APIs to set up a context of playback where the audio and video are synchronized within (which I don't know).
Apple has APIs and documentation to go with them on syncing audio and video. http://developer.apple.com
Obviously calling methods sequentially (serially) won't do what you are asking since each method call will take some finite amount of time, during which time the subsequent methods will be blocked.
To run multiple general-purpose tasks concurrently (potentially truly simultaneously on a modern multi-core device) you do need threading via "dispatch queues and stuff like that." GCD most certainly does work, so you are going to need to elaborate on what you mean by "they don't work."
But this is all probably for naught, because you aren't talking about general-purpose tasks. If you are handling audio and video tasks, you really shouldn't do all this with your own code on the CPU; you need hardware acceleration, and Apple provides frameworks to help. I'd probably start by taking a look at the AV Foundation framework, then, depending on what you are trying to do (you didn't really say in your question...) take a look at, variously, OpenAL, Core Video, and Core Audio. (There's a book out on the latter that's getting rave reviews, but I haven't seen it myself and, truth be told, I'm not an A/V developer.)
As you may know, in any multitasking environment (especially on single core devices), you'll not be able to have guarantees on timing between statements you're executing.
However, since you're mentioning playback of audio and video, Apple does provide some fundamentals that can accomplish this through its frameworks.
AVSynchronizedlayer - If some of your video or audio can playback from an AVPlayerItem (which supports a variety of formats), you can build a tree of other events which are synchronized with it, from keyframe animations to other AVPlayerItems.
If multiple audio tracks are what you're looking to in particular, there are some simpler constructs in Core Audio to do that too.
If you can give a more specific example of your needs someone may be able to provide additional ideas.
I'm building an app for iOS with Adobe Flex builder and compiling it into an .ipa using Adobe's tools.
Through initial testing, I see that the end result isn't as rich as native code, nor is it as fast or smooth.
Without simply saying 'why dont you just use objective-c', are there any documentation as to the overhead to building an app this way?
Specifically, what kind of performance hit can you expect when using Adobe's platform instead?
Make sure you are using the latest AIR 3.0 SDK for iOS packaging. It is notably higher performance.
Consider best practices when developing your app:
http://www.adobe.com/devnet/flash/articles/optimize_content_ios.html
http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
http://www.mikechambers.com/blog/files/presentations/fitc_amsterdam_2010/flash_iphone_fitc_2010.pdf
Blanket comparisons to native Objective-C is a wide topic, to which capability of Flash ubiquitous deployment to multiple platforms should also be considered if you're targeting Android and BlackBerry.
Perhaps citing specific issues of your implementation would help yield insight.
I too have been developing a Flash-based iOS app. My initial prototype was useless in an iPad 1. I had to look for ways to optimize. My second prototype is performing quite well. So here are some pointers.
1) Don't use timers. I had to write my own utility "FrameWorker" Singleton class to manage and delegate all my animations, or even delayed actions to a single enterFrame event. This alone will give you a huge speed boost.
2) Don't use many enterFrame events on different objects. As I said on point one, find a way to use a single enterFrame that you can add and remove processes to.
3) Avoid vectors as much as possible-use images. If you need to draw objects in the Flash IDE or via action script, use cacheAsBitmap = true.
4) Don't use visual objects that are much larger than the screen area. If you need to use large objects across the screen, then manage them off the display list and learn blitting techniques to draw to the screen ONLY the rect that will be display at that time. Lee Brimlow has a couple of good starter tutorials.
5) Be very disciplined about managing events. Make sure you always remove listeners that are not necessary anymore for instance.
6) Distribute your app's load to different frames. Don't do too many intensive things on a single frame.
If you follow these pointers your app will be as fast as any out there.
I understand that I have to use the UIAccelerometer to detect which angles that will exist in a regular golf swing.
The best equivalent that came to my mind is that I want to use the iPhone just like the Nintento Wii control.
Is it possible to swing the iPhone like a golf club and be able to decide:
Wheather it's a roughly accurate swing (if it's more like a tennis swing = throw error)
Perhaps store the angles the iphone registers on the "back swing". If I store five values each x second on the "back swing" and then check if these values are roughly equal to the "front swing".
I also need to decide how hard the swing is, perhaps if I can check this a moment before the iphone reaches the default position (start position before starting the swing movement). I know that I can't calculate the speed between two positions with UIAccelerometer, but maybe I can solve this in some other way?
Answer from Apple Review Team on this question
Thank you for contacting the App
Review team. Apple is not able to
provide pre-approval to developers for
proposed application submissions or to
review and comment on application
concepts, including business models.
That said, the concept does not
violate the guidelines; however, the
app will need to be evaluated to
ensure the implementation is in
compliance.
Personally I think an app like this would be approved, but an app where you is supposed to throw you device as near as possible to a location should be disapproved. This is how I interpret this.
Anyway, I've learned that my question, which was if the swing was possible, is absolutely doable with the usage of the Accelerometer with a High pass fitler and a Low pass filter.
Have in consideration: If you are about to develop an app with the same concept, don't get angry if it gets rejected.
There's a reasonable chance that Apple won't let an app like this into the app store. Read the human interface guidlines: they say to not encourage the user to do anything which might cause them to damage their device. And with doing a golf swing, I can imagine somebody somewhere letting go of their iPhone and then kablooie...
I'm working on a game where really the only game part is (at least right now) that the user can unlock achievements as she does various things throughout the game. I have a database that can keep track of certain user actions and record how many times a user does something but I'm having trouble figuring out the best way to architect the app so that I have to do the least amount of work. Kind of suck with the timing because gamecenter is not ready and it seems like openfeint is changing gears, but maybe I'm wrong. I'd prefer to do everything "in house" if it is not too ridiculous. looking for suggestions.
One of the parts I'm having the most trouble figuring out is how to manage the state of all the achievements. NSuserdefaults vs. core data vs. a flat data file.
Also is there anyway to send a notification if a core data field reaches a certain amount?
Thanks,
Nick
Are you keeping the achievements on the device only, or also on the server? On the device, there is no reason not to use Core Data.
Using Core Data, you could use KVO on your model properties to monitor when certain values reach a new achievements.
What kind of practices do you do when developing iPhone apps? For instance, do you write up a technical design document of any sort. Do you write down the design of your app at all? Do you implement a certain methodology agile/scrum/waterfall etc...? I'm just curious when working on projects like an iPhone app, what kind of best practices do people use or do people just go at it?
I've worked on a few iPhone apps, and I've found this workflow works pretty well:
Figure out what the app is going to do. Create a one sentence description of the app that embodies what you're trying to do. If you can't explain the core functionality in one sentence, people won't get it!
Create interface mockups for each screen of the app on paper, and then in Adobe Fireworks. Fireworks' native file format is PNG, so it's easy to create images for use in the actual app later.
Figure out how you're going to architect your app using Model-View-Controller and the other iPhone app design patterns (delegates, dataSources, etc...). Don't try to do something other than MVC. The whole SDK is built around MVC!
Start coding! I usually start with the bare functionality first. For a drawing app, I implement the drawing controller and the important drawing views (color picker, etc..) first. I back things up to an offsite SVN repository as I go using Versions (I haven't had much luck with the repository support in Xcode)
Distribute a beta version of the app to a group of AdHoc testers. This helps a lot. Getting the app in the hands of a few extra people really helps isolate usability issues and bugs that are hard for a single developer to find.
Repeat until satisfied and Apple approves :-)
I haven't done much with iPhone development, but its irrelevant. I wouldn't consider it any different from any other developmental process.
The process is different for each case, some have at it and others follow their development methodologies.
As one who is about to dabble in his first iPhone app, I don't think there is any one methodology that rules over any other. You can apply any of the techniques you mention to an iPhone app, just like any other development effort.
A key thing about iPhone apps, or any Apple related development effort, is that Apple sort of forces you to follow certain design guidelines. That is good in some ways (less to concern yourself with) and bad in others (restrictive).
Also, Objective-C and Cocoa Touch can also lend itself to certain ways of programming.
Now, specifically for me, as a sole developer, I will probably:
Jot down high level features of what I want to be included in the first version
Do an interface mockup (either on paper or with a software tool)
Jot down some key objects and functions (psuedo-code)
Set up a source control mechanism (I think this is key)
Start going at it
Possible repeat of any or all of 1-3 :-)
I prefer to start with small proof-of-principle projects to test out different capabilities of the device that I need for my final product. This is especially important on a mobile device like the iPhone, because hardware limits on memory, processing power, graphics, or display size can render some ideas impractical. It's best to know that your application won't work as you imagined after only a couple of days of playing around, rather than after a month of development.
John Geleynse and others at Apple advocate starting your design with a single sentence that describes your product and its intended audience, and building everything around that mission statement. I've found that this works extremely well for determining what features to incorporate or leave out of a product, particularly on the iPhone. Having a simple core product description at the center of your design is also extremely helpful when you need to explain this product to others in your later marketing efforts.
Aside from that, I've found that iterative development incorporating lots of testing and user feedback has worked for me on every platform I've developed for.