I am building an iphone app for my local high school football team. What is the best way to show live data for the scores of games without using a sql db and having to updated the entire app after every game.
there are a few ways of doing it, one would be to create an rss feed on a remote server, and parse that, and if you wanted realtime updates, you could use push notifications.
If you plan on creating the app to only show what the end result of each game was you can use NSXMLParser as #MCannon suggests. If you plan on having the app update in REAL TIME, as in. "The ball is on the 45 Yard line, 3rd and 3". Then you can stick with NSXMLParser but create a NSTimer to update the information every 30 seconds or so.
That would also mean you would need to have the RSS feed updated in real time as well.
The only way to do what you're asking is to have the data stored on the internet in some fashion, then build into your app a routine for consulting the remote data source (on the internet) and update its internal storage accordingly.
It can be done with no DB but the data must exist and be accessible over the internet. As others have suggested, an RSS feed would be a great way to pipe in the data.
Related
Edit: The answer is to use firebase realtime database.
I wrote a library for the next person.
https://github.com/flipflopapp/turnbased-games-with-firebase
-- Question --
I am implementing two player chess game (www.halfchess.com) and am considering using firebase messaging (instead of using sockets to create rooms and two player matches). The game would involve sending 60-100 chess moves as messages between two devices in two to three minutes (that can be android or iOS). My nodejs server would have code that enables device to device messaging (receiving from one player and sending to other).
I cannot use Google Game Services because I don't have google login implemented in my app (I only plan to keep facebook login). The advantages of using firebase (compared to sockets) is that I will have to write much lesser code (reconnections, etc) and it would take care of scalability issues.
My questions are :-
(1) Will there be problems when the users playing against each other are on two iOS devices (instead of android's)? (such as higher latency)
(2) If a user is changing location physically and a message that contains a chess move is undelivered, when will it be retried?
(3) For a fast game of chess, will the latency be manageable? This is like 8-10 times the speed of normal chatting.
While I read more on the topic, perhaps someone who has already experimented can comment.
Firebase Cloud Messaging is not meant for kind of usage, and in addition to a non guaranteed delivery time (some researches from 2013 - 2014 shows more than 1 seconds per message on avarage), FCM will probably imply throttling in such a use case.
See also this SO post
I'm sure the answers above will work but, I was having a tough time getting them to function. This is what eventually worked for me and my firebase chat app!
Hopefully, this will help some folks out there.
I was able to add a chess game to my firebase chat app and, all I used was an iframe! However, it didn't work the first time because, all I did was add the iframe coding to my app.
This is how I got my iframe to work in a firebase app...
First, change directory (cd) into your chat app's "public" folder (where you would typically run the "firebase deploy" command) and, add your iframe to the "index.html" document located there. Use this address for your iframe's source URL (src)...
src="chess/index.html"
It wont work right if you do not include the "index.html" page name!
Next, I created a new folder named "chess" in the same public directory and I added the chess game's "index.html" doc and dependanciess to it (js,css,images...etc).
And last, but not lease, open a terminal in the same "public" folder and run "firebase deploy" to upload the whole thing to your firebase account and console.
Done!
I'm pretty sure that including your chess app docs inside of your firebase app is what made the iframe finally work. I also wrapped the iframe with a couple of 'div' tags but, I'm not sure if that made any difference.
Please, feel free to come and take a look but, you'll have to sign in with Google to gain entry!
After that, just right-click anywhere on the page and select "view source" to see the code. Cheers!
https://friendly-chat-b2d6a.firebaseapp.com/
Instead of having the other player send a message to the client, why not just have the client display a message based on whats happening in the game? It seems like an easier solution for you, as the only thing that needs to be sent is the actual move, and you can piggyback off of that if you need to.
I realized I should be looking at Firebase Realtime database (and not messaging).
Useful links:
https://firebase.googleblog.com/2016/07/have-you-met-realtime-database.html
Is firebase realtime json database suitable for data broadcasting?
https://firebase.google.com/pricing/
https://groups.google.com/forum/#!topic/firebase-talk/n_B1nrgp580
(according to this talk the latencies can be < 200ms most of the times)
https://twitter.com/jonikorpi/status/733560092780462080
I am currently developing an app with a big database. Think of the app as similar to TripAdvisor in the following way: multiple cities with different databases, each between 5, 10, 20, 30 MBs. My whole app is based on this data: every view needs some part of it.
I'm having big trouble finding the correct way to handle this huge chunk of data. I am currently using CoreData: I think it is a great tool, and for offline mode, it definitely works great.
The problem is, I can't really combine it with "online" mode. If the user doesn't want to store the data for X/Y reason, I'm not sure how I should handle the data.
Simply allocate it in variables that will be released anyway, or is there a better way to handle the data?
Right now I am stocking it into CoreData without saving it: I know this is absolutely not a good way to manage it. How could I achieve this?
What is the best way to handle online data and then simply stock it if the user wants it offline too?
Option 1:
Data is always static/ not change data frequently:
You should have data on online. You can fetch data by webservice and store it to local database(i.e core -data). For example: Bible, Quran app.
Option 2:
Data change frequently and user need to update frequently:same as above. Additionally, from server you send notification(i,e push-notification) to app that server has a new data.After getting notification in app, download and save data to you database.
I am developing an app in which I am using SQLite database.what I am trying to implement is
Load data from server and add these data to local database.
Show data to user from local database not directly from server, so that if there is no internet connection user can see some old data.
This will be static data always but it will be huge amount of data.
Now I want to update this data for a particular time duration say in every 24 hours but this I want to do in background. This is about loading data but some data will be for uploading this will be small amount of data.
I have seen apple IOS-7 release features(Background fetch and Background Transfer Service),but what I understood is we can only download files from server by using this,I read this from this answer Here
but I have to deal with JSON. I have searched a lot how should I perform this but not getting any right solution.
I have this tutorial for background tasks
Background Transfer Service
there are many more tutorials but I am not getting how I can implement it in my case.
if I am not clear with my question please let me know I will provide more details.
Thanks for all help.
one more point I want to tell, database structure is almost same as server database.
In my opinion a better solution would be if you save the time of the latest update of the database. Whenever the user opens your app (this is the only time he wants to see new information) and your saved timestamp is at least 24hours ago, you should update the data in your database.
My question is to do with the backend service parse. So far, whenever I need something, I use a PFQuery to query the database. However, I now need something a little different, and have run into a slight wall.
I have a game app that records the all time high scores. Now, I want the app to auto-update the table of high scores as more come in. For example, if the first row is currently "Jimmy: 2505" and in parse suddenly another bit of data is added where Sam gets 2604, I want Sam to be at the top of the table now.
I realise that I could just continuously send a query to Parse say every 30 seconds to check for new data, but that would be terribly inefficient, and also expensive. Is there any way that I can use that allows auto-updating without sending a query all the time? Thanks
I'd suggest using push notifications. When the user opens the app, or uses a particular view controller, subscribe them to a channel that calls for updates when the high score list is updated. In your app delegate configure how you want the push notifications to be handled. You'll have to weigh the pros and cons of api requests generated using push notifications vs a default call to update the high score list every 30 seconds as you suggested in the OP.
Push notifications should be triggered through cloud code. When a new high score is generated make a cloud call that triggers the push notifications. You can specify the kind of push notification that you'll be sending.
Given the recent addition of local datastore for iOS to Parse, it should be possible to rely exclusively on Parse to manage app's database, thus totally avoiding Core Data. Does this sound like a good idea? What would be the pros and cons of such an approach?
In particular, I am wondering whether it will be possible to pre-populate Parse local datastore with some data, and include this database as a part of the app when submitting to appstore.
UPDATE
From the comments that were posted, it seems that people misunderstood my intended use case. Sorry guys, I should have made my question more clear from the beginning. Let me clarify it now, anyway.
So, there is some amount of data in Parse database on the web, same for every user, e.g. a catalogue of books. It will be updated every now and then. What I want is to publish an app on App Store which is pre-populated with Parse data store, as it stands at the moment when the app is published. For that to happen, I'd like to pin all available data when building my app and ship that data store along with the app. The problem is that the pinned data will be stored on device's (or emulator's) file system, it won't be part of the project. That's why if I build the app and submit it to app store, the data won'd be included.
Any suggestions how to attach the local data store to the app?
The local data store is stored in the sandboxed part of the filesystem in iOS. When you package the store with the app, it'll live in the signed application folder, not in the location Parse expects it to be.
So, if you were looking to do this, you'd need to include your default local data store in the application on building/submission, and copy it into the location Parse expects it to be in (which is Library/Private Documents/Parse and the file is called ParseOfflineStore) when your application starts up. This must happen before you call enableLocalDatastore, or an empty one will be initialized.
It should be possible!
Read this in the docs. Parse has a highly resourceful and fully documented guide for their backend.
https://parse.com/docs/ios_guide#localdatastore
Per my comment above concerning didFinishLaunchingWithOptions; it has been a place for your to create objects on launch, I have been doing that for a long time. Especially with channels. However, by enabling the local data store you can access those objects you pinned or created with a simple query with no reachability per your concern. Either way they both are created on disk. Core Data has a lot more cons. Especially with NSFetchedResultsController and the flexibility it offers. It's all up to you what you want to do with your app. PFQueryTableViewController isn't bad but if your direction and vision for your app is to be exclusively Parse then why not. It's a great feature. However I didn't see anything in the docs about the local queries effecting your limit so I would suggest looking into that if you have a large audience performing numerous queries per second.
Take advantage of their docs. They do a great job at keeping us informed.