I'm making a relatively simple text-based RPG Android game. I reckon it would be a good idea to allow players to save their game and load it later using a single slot (so it's more like a save/continue thing). I think I'd need to save the player's name, inventory items, and of course all decisions so far that made an impact on the game.
What is the best way to do this? I suppose the name and choices could be saved as variables somewhere, somehow, to be loaded into the game later. Inventory might be slightly trickier. I have been at Android development for some time now but never had to save anything like this before.
Depending on your choice of programming language and any software you might be using will depend on what is easiest for you.
Typically for any information saving like what you are doing I use ini files. It may be in your better interests to look into that.
Any more specific help you need I am more than happy to help.
Related
I have a profile page as a music curator account, where it shows the score for various parameters there. The most relevant one, monthly listeners, is easily inferred (just a simple excel that I've compiled with the values found on the page), but not shown.
Even though I can constantly calculate it (approximately, because the page might not be consistently updated or might have some flawed calculations), I'm still trying to find a way to have that monthly listeners value updated constantly, and seen as a graph over time.
I was wondering if it's best to do it on android, windows or any other way, to simplify for a complete noob like me, any coding process that i might have to do.
I've only had a little experience in Arduino, so even the basics as to what language to use or the code neccesary for this are foreign to me, but I'm quite interested in learning more about it.
Any help is appreciated, thanks!
How the app works
Currently an app is in the works which utility is to explore activities in 5 regions. Each activity is represented as an JS object with a fair amount of properties. Activities can be viewed through different filters in their respective tab, for example categories or a map. Inside each main filter, there are options to filter on date, region, accessibility etc.
The challenge
There is a lot of JSON that needs to be stored on the device, and support is required for both iOS and android.
In the best case scenario the data needs to be in sync with the database, and all data needs to be available on the device. The app will need to be snappy for a good experience, this means that fetching data needs to be as fast as possible. Furthermore, filtering data needs to be as snappy as possible.
Viable solutions considered so far (which don't quite cut it yet)
MongloDB with the MongloDB Titanium Store adapter, silver bullet?
This approach at first seemed be the silver bullet. Although the project seems promising, it is maintained by one heroic hacker, and the project is in need of some documentation. I have inspected the source, and hacked my way through the API, but to no avail, console.log and jasmine tests won't cut it this time. More important still, it is not quite finished yet, and features compared to MongoDB are missing. A great project, I hope it will catch on more and be capable enough to assist desperate titanium developers in the future.
JSONDB, only for iOS
This app really needs to work on both platforms, iOS and android, so no reason for trying this. Moreover, JSONDB works within a single context only, which would be a serious concern as well.
Ti Filesystem and JSON.stringify + JSON.parse, not memory efficient
A viable solution for saving a small list of saved items, which is also a feature in the app. But in other posts issues over memory limits with the use of JSON methods have been noticed for android. Though this might not be the least of my problem, memory efficiency overal will be a huge problem. Never have I seen benchmarks for performance with file reading and writing for Titanium, so I am not sure how big of an impact reading and writing would be. Filtering big objects is a huge concern as well, underscore won't manage this kind of big data. Iterating big objects is a huge problem no matter what approach I will choose.
Big ass global object
Practically the same approach as a Filesystem, only keep it in a global. This has the same issues and is just a plain unethical practice.
SQLite, yuck
Highly document oriented JSON data to SQlite, it sounds worse than samsung galaxy fanboys. Any feedback on this?
Multiple files + SQLite to maintain + lazy load, unicorns and rainbows?
Desperate for a solution, I might be onto something in the course of writing this post. There are probably something 10-16 main categories which each 1 to 4 subcategories. Keep all the activities for a subcategory in it's own file, which is a quite slim JSON. Browsing through categories, each subcategory is rendered in it's own TableViewSection, each subcategory be appended independently to the table based on how much the user is scrolled down, effectively lazy loading the content. There is only one quite quick file read. Within this view adding more subfilters effects only the already loaded items, and iterating this items is reasonably affordable.
Updating the data is also quite effective, only files that are subject to change are updated. A SQLite database can maintain the dates of all activities which have a expiry date, it can dynamically build it's own JSON file for the upcoming seven days or month. This will make the calendar view quite smooth for most usage. Picking future dates will be a nightmare though.
Still the map is an issue...
If you have read all of this, thank you. If you have experience with something similar, or might be onto something, feel free to reply! I have to quit writing, quit coding and start sleeping.
Sorry for the crappy monglodb docs. I developed it for some internal projects and really wanted to share it with the community, but the lack of docs does make it hard to use. But great news I have docs now lol also slimmed down and cleaned up the source code. Hope it works better for you now. http://monglodb.com
I'm the original author of JSONDB and thought I'd drop in and provide an answer for anyone finding this question via Googlefu.
JSONDB is now deprecated software - it's been replaced by another project called SculeJS. SculeJS aims to provide a full featured NoSQL database written in pure JavaScript for use in Titanium, NodeJS, and web apps.
JSONDB was originally only available for use in iOS applications due to limitations in the way Ti native modules were built - the current versions of JSONDB and SculeJS are compatible with both iOS and Android apps.
In a lot of ways MongloDB and SculeJS are similar, where they diverge is in the way SculeJS has been engineered. SculeJS is intended more to provide powerful, generic data structures with a rich query layer rather than being a straight port of MongoDB. No insult to Monglo - it looks like great software, I just wanted to point out the difference in intent between the two projects.
As a side note - all pure JavaScript modules are limited to to a single execution context within Titanium applications.
For what you're building I think MongloDB, JSONDB, SculeJS and TaffyDB would all do the job, the details of the implementation would just be slightly different.
I was encountering the same problem. I had about 5mb's of data which I wanted to store with the app, and not let it download.
I finally ended up with an SQLite database, with high performance. It is not as bad as you think. It might not be a nice solution ,but for the lack of choice it is a very good one IMHO.
Just create a couple of tables, and functions to parse them to database, and the other way around, and I promise you, you will be happy.
DO NOT store the JSON in the database, but store the values appropriately.
I'm very new to coding and have searched everywhere but havent been able to figure this one out.
Im trying to create a Lap Time Leader Board for various tracks in a video game guide. The user needs to be able to Click on the track name and then inside of the new layout "Create" a new time...that needs to allow him to imput the Car and the time it did on this track, then it needs to either sort itself or be manually sortable so that the times are in order from fastest to slowest. While i can build the layout easily i get stumped there.
How can i make it so that when the user clicks "Create New Time" the code gives him the spaces for time and car model.
How can i make sure it saves the correct info with SharedPreferences since each time will need to be saved differently (i think this has to do with the name and then ++ but i could be wrong)
How can i make it sort itself or be sortable for the user.
Can someone show me some sample code that does this? I dont know much of anything about SQL and would prefer not to use it if i can avoid it.
Im sorry this is such a noob set of questions but this after trying the notepad tutorial on AD and numerous video and book tutorials i havent found what i need to make this a reality.
You can always use a the Dialog class to create a pop up dialog to allow the user to input the information you are looking for. Sorry that you wish to not use SQL
Shared Preferences isn't such a good idea because you will have to do a lot more work to code your desired affect. A datatbase with simple Relations(tables) will suit your needs as opposed to Shared Preferences where you'd have to get creative to have the same data structure. Such as an ArrayList of BasicNameValuePairs, that could be a head ache. Database is the way to go, you can do everything you need if it's properly set up.
Sorting is quite easy in Java as you could always use the Collections class and implement the Comparable interface to compare your lap times to each other and sort them by total time. For a display such as that you would want to look into a TableLayout in Android XML. Don't worry so much about that, the Eclipse IDE will let you easily create and populate it. This would involve loading your laptimes from your database into a List and sorting them by time. It's a bit tricky but easy once you understand the Comparable interface and Collections if you need it.
If you need more insight post a comment, just wanted to share some ideas on how I would approach it.
so I am starting to learn how to develop Android Applications. I have experience with Java and C# from school, and I would say that while I am not a pro, I definitely have a fairly good handle on Object Oriented Programming.
So one thing I don't understand about Android is resources. For example, let's say I have a TextView in my GUI. Why do I have to define a string "Hello," then make the value that string called "Hello" = "hello?" I don't understand why the software development kit doesn't just let users make that string value "hello," and be done with it. What is the purpose of storing numbers and strings and stuff into resources? I know that there must be a solid explanation for this, but I just don't know what.
Also, I am experimenting with an Addition program (where I prompt the user with a randomized math problem, and they can input their answer, and my program will check if it is right or wrong, and restart). So I have a TextView for the problem (i.e., 1 + 1). When I create the TextView, I had to create a problemString in the resources, and then assign the problem TextView to the problemString. However, in my program, when the user has gotten the math problem right or wrong, I write over the problem with a new problem by simply changing the text of the textview. In no way do I interact with the problemString from the resources. And this works. So again, my question is, what is the purpose of having application resources and what role do they play in an application.
Also, how do I access, write over, and do stuff with the application resources.
Sorry that this is a really long question, but I really think Android dev. is really cool, and I am very eager to learn. Any help is APPRECIATED! xD
Thanks!
Imagine your application with a thousand different strings to display to a user. If you need to change 30 of them, do you want to dig through all your code, or one file?
Also localization is another reason for having different sets of string resources, as well as other resources, specific to a locale. Take the above scenario, a thousand different strings, AND three different languages. How would you handle that? Three different version programs? No.
First time posting and first time working on Android, so go easy if I am breaking any rules :)
Anyways, I just got into making an Android app and I'm trying to create a simple trivia game. I plan to have many questions (hopefully about 5000+ questions) made. No data manipulation made, just straight up reading the questions and presenting it to the user. I am now faced with the dilema in how to store the questions.
I have two choices:
1.) Bundle the questions with the app: Possibly store the information in SQLite. Originally, for demo purposes, I placed the questions in an XML file, but I quickly realized how inefficient it will be once the questions start piling up. First, I am concerned if opening up such a huge XML file would suck up Android's memory. Secondly, I am worried how large the app would be if it contains 5000+ questions. I read here about the pros of XML vs SQLite. In that example, the user has 70,000 entries so maybe my 5,000 questions would be enough?
OR
2.) Host the questions on a server: I believe the upside is the app wouldn't need to be bundled with a vast amount of questions and wouldn't need to worry about the logic of opening and assembling the questions. It would just hit a PHP page and depending on the parameters sent, the PHP page would return the questions in XML format. The downside is the user would need to be online (to retrieve the questions) in order to play the game and my server would need to be up and running 24/7.
Has anyone encountered this design issue of how and where to store vast amount of data in an Android app?
Thanks, any help would be much appreciated!
From a marketing perspective, I think the right approach is #1. Just looking at the top app list, it's filled with apps that work offline. I don't know why most people fail to mention this one important criteria when they talk about marketing apps... especially in Android, where lots of people don't have a data plan. Plus, a trivia app sounds like something someone would probably use during a commute in a train as opposed to something like Facebook Chat that they'd use when they're online.
From a technical perspective, storing 5000+ questions really won't take a huge amount of space. There's this app called "MyFitnessPal". It stores maybe over 30,000 foods in a SQlite database, with nutritional information. So don't overestimate how much space it will take.
The advantage of going with #2 is if the questions or answers change often, you might want to go with that approach.
I think that the best option for you is to store the questions in SQLite.This way the users can have access to your game even if they are offline,which is one of the important things as Hisoka mentioned. So I think you should try using SQLite.