I am loading a GPX file into my emulator.
THE PROBLEM
The file has 7226 points (it says so in the Point Count column) so the file is being loaded in correctly. However, the problem happens when I press the play button it only reads in about 4 points before it then pauses itself. This is not the functionality I want.
THE QUESTION
How do I make it run through the entire file without it pausing itself?
Thanks in advance
Just for the sake of answering the question from my research and for those of you looking for a solution yourself.
I couldn't manage to get the entire GPX file loaded in via the DDMS even when using different types of converters that you can find online.
The solution in the end was to have a set of classes which decode a GPX file into a set of locations and then do whatever you want with those.
I hope this helps even it is just confirming your thoughts that it wont work (well i couldn't work it out!) :)
Related
I have been scouring the internet for a simple easy to implement Android file chooser dialog that also has the option of selecting multiple files and returning a uri or string array with all the files selected.
Currently I use aFileChooser on github and it is according to me better than android-file-dialog. But neither address the issue of passing multiple files.
I am only an intermediate android developer but I think this would be something not so hard to implement by a pro.
I have looked at the code of aFileChooser and I think adding a check box to the file item would be the way to go but as far as code is concerned i am clueless and the developer seems he's not really gonna work on it in the foreseeable future
So in short im requesting for help to either add the select multiple files option to aFileChooser via the github or here, or maybe suggest to me a better dialog that does what i want.
I don't know any file chooser you could use, but I can show you how I made my own long time ago. It's actually pretty ugly, but it does what you ask for. You can select multiple files and an ArrayList<File> is returned via Intent.
So you could use it as an example of how to do it, and implement it yourself, if you really need it to (I wouldn't recommend you to use mine as it is now).
Here are the links to GitHub:
FileSelectionActivity.
Used layout file for the FileSelectionActivity.
MainActivity, on line 225 the FileSelectionActivity is started.
Below there's a screenshot of FileSelectionActivity, as I said, ugly.
"Go Up" goes to a higher level of the file hierarchy, there are two ListViews, one for directories and one for files. The files have checkboxes. When the share button is pressed, each item in the second ListView is checked to see if the checkbox is active or not. That's line 71 of the FileSelectionActivity file.
Anyways, I hope this helps you make your own file selector, or something.
Thank's to the answer above, I've made a simple library that addresses the concern. It not only passes an array of file paths but you can also use to select a folder.
It has thumbnails for image files
auto scrolls to last scroll position
will soon have language support for several locales
Here it is: https://github.com/tapaulo/Android-Multiple-file-Selector-Dialog
I'm just wondering how the following scenario can be solved:
I want to write a very simple app for my daughter. The app displays 4 colored fields on the activity and through speech output says something like "tap green". She should then tap the green field to get positive feedback. So far, so easy.
I then thought it might be nice if the app would also "grow" as she grows older. Maybe later I want to have a game mode where I display animals, numbers, vehicles, etc., so it would be nice if I could have something like "Shape sets" - basically a set of images along with a description of what the app should say for each image. Also easy enough - all you need is a set of images and an XML file describing the images.
BUT
I'd like to be able to install these "Shape sets" as additional APKs later on, so that I don't have to modify the app every time. I'd like to install the APKs, so that the contents are added to a specific sub folder on the SD card, into which my app looks to enumerate available "Shape sets".
If I ever published the app to the Play Store, other people should also be able to download the "Shape sets" I create (no need for user contributions, though).
Is that possible? If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card? Or is there even another way of achieving what I want that I didn't think of?
The term "plugin architecture" just came to my mind as I wrote the question. Searching using that term I found this question: Extend my android app in different APK
It seems to provide a solution to my problem - I'll investigate this further, but please feel free to suggest other possible solutions!
Is that possible?
Um, sure.
If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card?
Android won't do any of that. You have to do that. You would have to detect that a "shape set" APK was installed (either watching for package-installed broadcasts, scanning all installed apps for ones that seem to be a "shape set", etc.). Then you would have to arrange to copy whatever you wanted to wherever you wanted it, either by:
Asking the "shape set" app to do it (e.g., send a command to some IntentService), or
Using createPackageContext() and trying to do the copying from your main app
Or is there even another way of achieving what I want that I didn't think of?
Um, just use ZIP files that your app downloads itself from a well-known location. That corresponds to Dave Smith's final paragraph of his answer on the question you just linked to in your edit.
Or, just update the main app. I'm not quite certain what effort you think that you are saving otherwise.
Or, just keep the content online, using a Web service to indicate the available "shape sets" and downloading them as needed (with optional caching).
Fascinating question. If you really want to go for plug-ins then OSGi would probably be the way to go, but it's a lot of work to get to know and to use and seems like overkill in this case.
I don't know how your shapes are defined, but they are probably each defined in a separate file-set, providing the shape (maybe a png or jpg?) as well as the audio-file that will be used as a command for this shape. If the folder in which these file-sets are stored is fixed (TapGame/Shape Sets/...) the app could scan the folder each startup and the views could be generated accordingly (in this case, the activity cannot be build entirely in the XML-File, but must be partially done programmatically).
The Plugin-Aps would be rather easy. They are an apk which includes the file sets (jpg and mp3 or whatever). Started once they deposit all these files into the specified folder (they probably check before if these files exist) and then the apk can shut down again and be uninstalled.
on the next startup the Tap Game App would find the new symbols and include them into the game.
This seems rather straight forward to me. Another way would be to actually store the shapes and audio files on the internet and with each start of the App check if the number of shapes and audio-files has changed and create local copies of new ones. This would mean no downloads of apks... probably a more usual approach to the issue.
I am very interested to hear what you make of it, seems like a different approach then the norm, which is always cool to see.
With the fantastic help of Tim on this thread Controlling Android app with bluetooth mouse/ presenter I added bluetooth remote control of my application. After finishing this, I noticed my apk file went from 175k all the way to 1711k - 10 times larger! I have implemented the bluetooth changes on a test application without seeing any change in file size so I am not sure what caused this. I did have some kind of Eclipse problem in the middle of this and had to do a rebuild to get the source to run again so maybe that had something to do with it.
Searching for file size change here and on Google gives me questions of people who want to make larger files to hold more stuff, not my question. I can't seem to find relevant answers.
The application has no graphics, pdf's, or other files of any size at all. It just reads some GPS stuff, does some math, and displays the results as text.
Is there some way to get the file size back down? Is there an Eclipse option? This is my first real (non test) application and it is finished and working but I am concerned with the file size increase.
You can check the contents of apk file easily. An apk file is simply a zip file with different extension. Just replace .apk with .zip and unzip it. Then diff the contents with your previous .apk file and find out what file makes the difference.
I encountered a similar problem with the APK size. One way to check out which resources are the culprits is to 'Open Editor Log' in Console.
Some helpful explanations can be found here:
Unity build project game 2d to apk with huge size because textures
https://docs.unity3d.com/432/Documentation/Manual/ReducingFilesize.html
I am working with osmdroid map viewer in offline mode. I have downloaded tiles with Mobile Atlas creator with osmdroid zip format and everything is ok. I want to know that is it possible to have more than one zip file? I just want 2 or 3 different locations that are far away from each other.
any help?
Yes, you can have more than one zip file in the folder. I have 3 files corresponding to different areas on my device. They all give me a map display when offline.
I was thinking that there is always one zip file for one layer - like mapinik, osmarender etc.
But... I looked into the code and it seems that you might be able to do so.
Take a look inside of zip file and if there is structure like: mapinik/zoomLevel/x/y - you should be able to add another file with same structure which should work.
I see that the code is looking inside all archive files for tile path. Im just not sure what "all archive files" meens and I have no time to investigate or test this :)
Hope that helped a little bit.
OutOfMemory exception is because heapsize is full. Most/all of Android phones have small heapsize (from 16 to 48mb). There should be also a workaround - to export data into SQLite instead of ZIP, atlas creator can also do that.
I havent seen OSMdroid code for a while but Im pretty sure he can also read this kind of stuff and you will not have a OutOfMemory problem then. One thing about SQLite is 2gb limit but it's still not bad.
So, largely for debugging purposes, I want to be able to write an image at arbitrary points in my code, and look at it later. I figured this would be easiest if I just wrote a my bitmap to a file and read it back later, but I cannot seem to figure out where to find the file after I write it, or how to open an image that is not in res/drawable with a corresponding handle in R.
You can use openFileOutput() and openFileInput(). These pull up data streams that point to files in your app's directory, and are (as far as I know), the suggested way to handle files that your app makes.