When using in-app audio in the iPhone SDK, it is possible to allow users to select a list from their ipod library and create an in-app local playlist. If I want to persist this choice, it is easy to serialize the data and write to file, then recover.
Just vanilla like this, however, leads me to think there is going to be something wrong. For example, what if the user syncs and removes sounds? I can loop across them all and query the iPod DB at setup time, but with lists that could be 50,000 long, this could take some time.
How are other people doing this and what are some gotchas that I haven't though about?
I would just do it lazily,
If a user wants to play a song, you could query the iPod DB, for that song in particular and maybe the whole song "Album" in case the user removed the Album. This would require two requests to the database before playing each song, but you could benchmark if it's fast enough, etc.
You could also put an option somewhere to "sync" the application with the iPod DB, but given as a choice for the user, giving the user a "warning" that it could take a while, maybe even giving him a time estimation for the size of his particular library.
I think that from a usability/battery saving point of view, this would be better than querying the whole database each time your application starts, or even in the background.
I initially posted a response around saving the individual MPMediaItems. After some thought and a reread of the documentation for MPMediaPickerControllerDelegate, I think the approach to use is to save the representiveItem property of the MPMediaItemCollection and use that to construct an MPMediaQuery at runtime.
Related
I have an NFC tag that has integrated environmental sensors inside (MLX90129 to be exact). I would like to make an iPhone app that can read the realtime data from the tag multiple times per second and graph them. I'm not looking for background tag reading, and you can assume that the app will be open and the phone is near the tag at all times.
From what I can see on Apple documentation and other sources, the Swift support for NFC tags is mostly built for single session interrogation. Has anyone succeeded in getting continuous and repeated NFC tag reading for this type of purpose?
As you pointed out: "to make continuous and repeated NFC readings" it's not the intended functionality.
While I think that you can sort this out, there's another thing that could be a headache... to make multiple readings per second it's directly confronted to the current implementation of NFC tag reading in iOS.
Every time you start a reading, it shows the native window which informs the user that you are making a NFC Reading. A part of this process is the interaction of the user, and is exactly that part the one that imposes a time constraint. Even if the interaction with the user is not needed, there is an animation, and that animation has its lifecycle's events (start reading, reading, OK, KO, close...).
Afaik you can't bypass that animation which definitely could represent a couple seconds in the best case.
With that said, you should have a few things in mind, if you still want to try:
NFCTagReaderSession can only have one active reading at a time, and when that reading ends (OK/KO), it should be invalidated. So if you want to make another reading, you'll need to create and configure a new instance.
we're attempting to track a streaming video with SiteCatalyst.The issue comes in as this video has obsviously no end and the s.media Module can't know how to set the seconds or milestones segment views.This is resulting in no tracking calls except for the starting one.Could a possible solution be the usage of s.media.monitor custom functions?Here's explained how to use them together with the basic Media module settings.Maybe a timing deployment of "sendRequest()" method could help...?I use this occasion to ask a brief how-to example of media.monitor methods, because I've been just using the basic settings till now, as below:
s.loadModule("Media");
s.Media.autoTrack = false;
s.Media.trackMilestones = "25,50";
s.Media.segmentByMilestones = true;... ...Thanks a lot
Yeah.. i really, really dislike the Media module. Video tracking is getting more and more popular with the clients, so it has become the biggest thorn in my side, because the nature of videos over the internet is a big mess with all kinds of moving parts internally, that make it extremely difficult to get truly accurate tracking beyond basic "start" and "stop". (actually I take that back.. I think mobile/sdk tracking is quickly becoming the thing i shake my angry fist at the most, but that's a different post!)
I think Adobe has made some heroic efforts to automate video tracking and it more or less works okay if you just have a regular (not flash) object or html5 tag embedded on the page but in practice, MOST of the time, sites implement their videos through 3rd party scripts (e.g. jwplayer, vimeo, youtube api) and the Media module automation basically goes down the drain on that count.
I understand that it needs to know how long a video is to know when to autopop the events, but I swear, 99% of the time in practice, the way Media module expects things to pop in certain orders etc.. it just doesn't align with how videos work in the real world. Even if you attempt to do it the "manual" way, more often than not it's still buggy,e.g. autoplay and buffering ALWAYS seem to screw up the open+play sequence that MUST happen in that order.
Basically, the Media module desperately needs to be rewritten to better handle streaming videos, and also just "manually" using it in general. Anyways..
Two things I have done in your situation. Overall, neither one of these options are a perfect 1:1 to normal videos with a duration, but then, streaming videos aren't really the same, so it doesn't really make sense to treat them the same.
Option #1: Use an estimated duration for your streaming video. So you said it yourself: your streaming videos have no end. Well as I mentioned, you can't calculate percent viewed unless you have a duration, pretty basic math. So, estimate a duration.
I have clients that have streaming webinars or whatever and it's true that there's technically no duration according to the player, but in reality they don't really conduct that webinar 24/7 forever. In reality it's for a set amount of time like 30 minutes or an hour or something. So, just specify the duration as that.
Yes, this will require extra custom work on your end to store/associate an estimated duration. And yes, this does have the potential for being misleading (e.g. if a webinar ends early or runs late). This option is generally good for sites that have set windows for the stream to actually be active.
Option #2: Ditch the notion of % viewed, record it as n time consumed. So the overall point of the milestones is to know how much of a video was actually watched, yes? Well, who said it has to be measured by % viewed?
How about instead, you just record n seconds consumed every n seconds. You can do this with an incrementor eVar, and/or counter event. (Part of the normal video tracking actually does include a counter event "Video Time", or a.media.timePlayed).
So basically, you'd basically just pop the events/props/eVars yourself, and ignore milestone/segment reports.
Note: This option only really works if you are using the older style video tracking that has events/props/eVars assigned for it. If you are using the newer style video tracking that does not use events/props/eVars.. well, AA does not currently offer an official way to manually pop that stuff directly. It is surely possible to unofficially do so, but I have not yet reverse engineered the latest Media module to figure out how to do that. So, in this case your only option is #1.
I'm trying to make some simple flash games but before I start purring mega bytes of data into the game it's better to seek wisdom from pro coders since I;m totally new to AS3.
1st Question is: what's the best way to load the game faster?
since bandwidth is limited like hell for me and loading a flash game takes some time I'm trying to make the game start as fast as possible and load the rest of materials in the gaming process.I saw this on lots of facebook games.
2nd: how to keep the RAM usage low?
do you advise to remove the loaded image/movie clip from the stage as soon as its out of the frame? does this lower the RAM usage? and if I load the removed object again does it use the loaded one or it start to download it from the source folder again?
3rd: whats the trick to load the materials into client PC?
I saw many facebook games that take some time to load for the first time but next day it loads like its data is stored on the Hard disk. do I have to do something or flash player does it automatically?
4th:Is there a way to load the images/movie clips into flash player while playing? I mean if the level of games are movie clips and player is playing first level the game continue to load next level and on then ad them to the stage as demanded by code.
Lead me with your experience please.
These tricks are not as simple, but yes, all of this is possible.
The "best" way to load the game faster is a fiction, you will anyway need at least the main game code to be loaded in order to play the game. If your levels are pretty huge, yes, you can load levels after actually loading the game. You can also load music the same way. For this, you will need a separate SWF or a set of URLs to get these from, and after your game fully loads (without sounds, levels or whatever you were capable of placing aside) you initiate an asynchronous load request (use Loader class for this) and after it completes, you'll be able to play either one sound, or one level, or total set of sounds or levels, depending on how do you organize your external asset storage.
The short answer is "reduce, reuse, recycle", that is, you'd better store big assets like a bitmap (an instance of BitmapData class) as a single object, and use references to display numerous copies of it throughout the game. You'd better use an object several times, say a bullet that flied once and expired, hit something, missed and left screen, etc, can be told "go back right here, here's your new parameters" and the object will not be wasted. Other tricks are also possible.
This is an automatic action of Flash player, or rather the browser, known as "local cache". If you request something off an URL, the request is passed to the browser, which, after downloading, stores a local copy for future reference. The storage is still limited, and also the copy can "expire" if it was stored for too long, which makes the browser re-download the URL content. Flash player uses browser's URL retrival, thus local caching applies to SWFs or other kind of data.
You can make levels into metadata, that is, you are downloading a set of different data via any means possible, then you parse that set, create the required MovieClip (or a Sprite) via code, stuff all the assets into it at intended positions and go with that. A metadata can be fairly large, and can be placed elsewhere as any other file you can share via Internet and download by an URL. Use Loader class to call for URLs and get data retrieved from the net, devise a way to properly store the metadata and a generator+parser to manage those levels as you design the game.
Hope this helps.
I have noticed that for a mobile application, saving on the main thread seems to take a bit when it compares to other applications on the device. Is it recommended to only save Core Data when the application enters the background or when an application closes instead of anytime items are added and sent / received from the api?
That's kind of a broad question, but I've found that saving core data after VewDidAppear statements is better than viewWill statements. Giving the user something to engage with and persisting makes it less noticeable than on a load. However, if a user is used to waiting for something like an activity loop, adding the save to that doesn't tax it too much (IMHO).
Not sure this help, just my experience.
I'm currently working on a new game for iOS using Cocos2D. The game needs to advance states after x amount of time since the first launch. So for example:
State - Time
initial launch
24hrs
48hrs
My first idea was to just get the data and time on first launch and save it to a file. Then I could check it ever now and again to see how much time has passed. The problem with this is I need it to be in realtime so that the changes will take effect immediately once the state is reached. It also needs to continue when the user is not using the app. The functionality I'm looking for is kind of similar to how the iOS strategy games work where you build structures that take x amount of time.
Anyway my question(s) is; is there some sort of library that can accomplish this and how can I get it to continue after the user exits the app?
It can't. There is - apart from kind of misusing video/music playing etc. no way for your app to do work while it is not running.
You have two things you can do to simulate that behavior (and I suppose the strategy games do this, too):
You can calculate at any time while a user is still running your app the points in the future when something should happen (eg a housing structure is finished). When the user leave your app, store these future times as local events - then the user will get notified that something has happened in your game (eg message "The church has been built. Do you want to go to church now?)". Pressing yes will open your app, and you can do whatever is necessary to indeed build the church. So in fact you don't do it at the time when it occurred, but when the user opens your app the next time.
Like 1, but without notification. Just remember when the user leaves the app (eg in your settings, I would use a property list; set it when the app delegate gets the appWillResignActive event), and the next time he starts do whatever would have been done in the meantime - he won't be able to tell the difference :-).
It's all about make believe here :-).