Develop Reference

Java, Codename One: Exporting and -most importantly- importing files between users

Here the problem: my app will generate some files, and I want to give to the users the opportunity to exchange these files between them.
This requires 3 steps:
Saving the data: easily done in Storage implementing the
functions required by the Externalizable class;
Sharing the data: done (probably, right now it's impossible to check if the
result is correct because the missing step 3) with the sharing
methods offered by the framework, as soon as I understood I needed
to use as mimetype "application/octect-stream";
importing the downloaded data (shared by another user): this one I can't manage to
find a way to make it work. Loading the files from the app's Storage
is easy, but accessing to the folders out of the app's Storage is
something I can't manage to do.
I used FileSystemStorage in the hope of gaining access at least to the Download folder that (mostly) every phone has, but apparently I can't manage to accomplish the task
Using the FileSystemStorage on Android, for example, I have access to
/storage/emulated/0
/storage/emulated/legacy
file:///system
The first two being related to the Storage of the app.
Acceding to file:/// I obtain a long list of folders, a partial list including
media
logs
sdcard
Removable
...
root
...
But when I try to access some of these, they all appear to be empty. Either I make some mistake or the app can't see their content.
So I wonder if there is a way to accomplish the task, namely to have access to the files (probably in the Download folder) the user has downloaded, to import them.

Phone apps live in isolation within the phone. Android literally creates a separate Linux user for every app so they don't step on each other and damage the phone. iOS does similar tricks.
As a result apps can't just write a file to downloads and can't just list all the files there. This would violate the users privacy. So the native API to share a file is usually separate from the files API. We do have a share API in the CN class which lets you share images etc. to an arbitrary OS app. See isNativeShareSupported and share.

Ok, maybe I found a solution for reading the files from the Download folder in an extension of CodenameOne called FileChooser.
According to this blog post it should give access to, between the others, the Download folder (at least in Android).
I'm going to try it and, when everything is ready and tested, edit this reply to say how it worked out for me.

Android Room database created 3 files including -shm and -wal files

I have created a database using Room database library with name ImageDatabase, when I opened my Device File explorer in Android studio inside the database folder there were three files with names ImageDatabase, ImageDatabase-shm and ImageDatabase-wal. I wanted to know what are these files meant for? Any help would be great
Thanx All

The data in your database is contained in all three. The one with no extension is the main database. The others are the Write Ahead Log file (-wal) and the Shared Memory file (-shm). They are used by the underlying SQLite system to improve performance, and contain the latest changes to the main database until a checkpoint is done. You can find more information in the SQLite docs.

Your original database is ImageDatabase i.e name of database you give at the time of creation.
you can copy database and check the contain from here
upload your database in above link and you can verify it.

Most suitable location to store uploaded images using the Spring Framework

I am currently developing a web application for a local company using Java, Spring Framework and MySQL no ORM. This is the first time I have dealt with uploading files.
My situation is that part of the system allows an admin user to upload images for store items.
currently all my resources such as images are organised and located like such: (located in the unpacked .war at the ROOT of my tomcat server)
/resources/img/items/
/resources/img/items/thumbnails
However I have come to the realisation that when the web app is deployed and a user uploads an image, it will be stored in the above locations. Therefore when I redeploy, the uploaded images will not be present.
My question, is there a better location to store these images? Or am I missing something. I have been researching for the past couple of hours and seem to have not gotten far. I'd be very thankful to anyone who could offer some knowledge. Thanks in advance.

There are many options where to store files.
MySQL: Store them in your MySQL database using the BLOB datatype. The advantage is that you have all your persistent data in a single location which is handy when doing backups. On the other hand, image data may bloat your database quickly.
In the file system: Store them in the file system, e.g. in /var/yourapp/uploaded-images. You need to tell your application about where to find that directory. There are many ways to do this:
create a configuration table in your MYSQL and put the folder there
let your web container/server provide that variable
via JNDI service
...
Make sure you have a rescue plan when that disk crashes with tons of data ^^
Separate Database
Since image data may bloat your database quickly, you may want to use another database for your images. In many architectures binary data are separated from the "real" business data.
I guess these are the typical solutions to your problem. However, there is no standard recommendation what to choose for it depends on facts you didn't provide, or cannot provide at the moment:
Are the images business-critical (technical drawings)
Size of the images (8kB JPEG vs. 200 MB raw image)
What are the demands of your users and who are they (SaaS vs small intranet application)
... many more ;)
Whatever you choose, it is better than storing files in the exploded war :)

SQLite on Google App Engine

Is it possible to use SQLite as a relational database from Google App Engine? (Java) I need read/write access to it from the app itself.
Also, I am using Quercus for PHP, and if what I am asking for is possible, I can handle storing the database myself.

No, it is not possible. This would require write access to the filesystem, which App Engine does not allow.
SQL database support (MySQL like) is planned, but no release data has been given. For now, use the datastore.

I know it's a super old question and nothing concerning read-only properties of App Engine has changed since then... But actually you can use sqlite on Google App Engine. There is a writable /tmp directory (https://cloud.google.com/appengine/docs/standard/java-gen2/using-temp-files). If your app on startup first copies the db.sqlite3 file to /tmp/db.sqlite3 and references this path as database path, it will work.
The following problems are connected with this approach:
This directory is "in-memory". So if you want to use really large sqlite file, you may face problems with RAM.
Each node of the app gets its own copy of the database. If you save something on one node, these changes will not be seen by other nodes. And the new data will be lost if the app scales to 0.

Holding Information in Android App

I've only just started to write in Java on Android, so please bear with me.
I have some settings I want to hold in my app, normally I would have used an xml file. Trouble is i'm not sure how to load it into the xml parser to read it.
I thought I might be able to drop it into /res/values/Info.xml and open it from there but it does'nt find the file.
I have also read that people are starting to use a SQLite database to hold information in, is this more the standard way to go?
thanks a lot
Luke

It sounds like what you want are Shared Preferences. Its a simple way of storing key value pairs, along with a UI for letting the user change them.

You could try storing to External Files (that way they can save settings on an SD card if they have 2.2). You wouldn't be able to modify the files in the res folder like you tried because these files get compiled into the app package. You could also try Internal Files found on the same page. SQLite might be a bit much for config settings.