In my codenameone app (ios/android) i want the user to be able to print out what is rendered on the screen. This could be tabular information or maybe a certificate of their achievement.
But what options are open to me get that screen content onto A4 paper?
FYI to generate the formatted screen, the app will have received the JSON data from a Dropbox MySQL database, and then formatted as normal.
From reading this forum, I know that direct print is not a feature of apps, so my next route is to use the ShareButton object in CN1 and get the user to basically export the screen content to a 3rd party app, which can print. But this is limited to text strings or photos (not both) and so a tabular screen would not export correctly. I also expect that doing this from an iPhone to the Mail app would not be fit for A4 size.
The mobile browser does this very well by being able to export to the PDR reader but that PDR reader isn't an option when exporting from apps.
Thanks in advance.
Recent versions of Share allow sharing both text and an image as far as I know so this should work. Generally the most common approach I've seen is to generate a PDF on the server and then use Display.execute() to run the PDF file which launches the OS native viewer.
I know some folks did some work on print integration based on questions asked here and in the forum but I don't know if they succeeded. There is nothing contributed back as far as I know.
Related
Wondering if anyone can help me out here. I have an input on a webpage that should only allow document files (not images). I have the "accept" parameter like so:
accept=".txt,.rtf,.pdf,.doc,.docx,.zip"
However it seems that on mobile phones (have tested multiple iOS devices and Android) it gives the user the ability to take a photo or upload.
Does anyone know a surefire way to prevent these options from showing? Typically iOS/Android have mechanisms that will respect the functionality of the HTML (like changing the keyboard for an input type number vs text), but here it seems like it doesn't care that I am trying to limit the file type.
In my case, the server will catch it and reject the image if they do upload it, but I'd really like them not to even get to that step by hiding that option.
On iOS, I'd like it to just say "browse", and on Android I'd like it to just say "Documents".
I realize my options are probably incredibly limited here, but I just wanted to know if I'm being stupid and if anyone had run into this issue with uploading files on mobile devices.
Thanks in advance, everyone!
My question will be really long but I encourage you to read through everything as it will be used for an honest, good cause. Or you can skip to the highlighted questions part.
Let me introduce myself first, I am an independent web application developer here in the Philippines and I work for a non-profit organization where we help less fortunate people by providing IT solutions and services for free. I have a working web application that has dynamic registration forms where users can enter their data online. I developed this application with responsive UI using bootstrap's grid system. But being here in the Philippines, there are remote areas where the target clients don't have access to the internet 24/7, and bringing laptop or desktop computers is a pain because of the terrain and rivers that we need to cross to reach these remote areas.
Now, together with my team, we are thinking of a way to use our mobile phones, mostly androids to create a mobile app version of our web application. Where it can download the registration form (html) when we are connected and then use it even without internet connection.
Ideally the situation should be:
1. Launch the app from my mobile, and while connected to the internet, download the html forms needed from our web application.
2. Travel to remote areas, use the mobile application to encode the native's information offline. (I heard its possible to save it locally to sqlite db)
3. Go back to the headquarters and sync with the online web application to pass all the information gathered and thats it.
Having said all that, I have 3 questions:
1. What should I use to create a mobile app that can display html forms downloaded from the internet?
2. How can I save the data locally (within the phone)? I heard about sqlite db but I am not sure if it will work with my situation.
3. How can I sync the locally saved data to the online web application?
This is more like a survey application. You dont need the html here. You design your question definitions in xml or json. You may have multiple types of question like Text Answer Question, Single Choice Multiple Option Question, Multiple Choice Multiple Option question, Image Question, QR Code Question, GPS Coordinate Question etc etc. You design these questions in json or xml and put them in server. For example
{
questionSetName: "Question Set 1",
question:[{
questionText: "What is your name ?",
questionType: "TextAnswer"
},
{
questionText: "Which one console below do you own ?",
questionType: "SingleChoiceMultipleOption",
options:["PS4", "XBox", "Steam Console"]
}]
}
Now for your mobile client:
When online user will want to download questions for later offline surveys. so user send a request to server for available question sets. then will pull these file from server (in case of android through some HttpClient like OkHttpClient) and put them in sd card. The server will implement rest apis for question lists and downloading individual question sets.
The application will check if files are present in a certain folder (your app designated folder) in the sdcard. The file names will be the list of the questions.It will parse the json or xml and render question windows accordingly, for example for text question a label with the question text and a text box for answer, for single choice multiple options a set of option buttons, for image questions open the mobile camera etc.
When filling up (answering) the questions you save the answers and question number and flush them in a json file. and put the answer files in another directory (you need some sort of identification).
later on upload the answer files to server.
The server side will require the following rest apis :
1. List of Question Sets of a user (from db ??)
2. An api (webservice) to download a set of questions.
3. An api to upload an answer sheet for a question.
4. user management of course.
Hope this helps.
I am trying to create an Android app where people can read short stories. The stories will be in the form of images since it will include some arts to accompany the text. That is the reason of why I decided to use Google App Engine. I want to store the images in the App Engine then let the client device retrieve all the stories(or images). I can then somehow organise the images into the proper sequence (which I have not an idea on how to do).
I am completely new to Cloud computing or doing backend stuff so there is a lot of stuff that I am not wrapping my head around.
I did a tutorial on creating a mobile assistant app. In the end I got it working and deployed to App Engine. Whenever I upload the files I did it through the command line using "appcfg.py" however after looking at Blobstorage it seems to work a bit differently.
How exactly do you upload images to Blobstore? So far all the thing I've read is on uploading data from the client device/web application and I can't seem to find anything that is very detailed on using Blobstore and Android together. What I am trying to ask is, is there a way to upload the images to the Blobstore directly from the command line (if that is possible)? And how to handle those images once it's up in Blobstore?
Can someone give me some advice please?
What is the best way to integrate a PDF document into my droid app?
I am attempting to recreate the same functionality we provide on our website in our mobile app.
I have 2 options of delivering the PDF to the device but the route I choose depends on the best way to implement this functionality on the device.
I could stream the document do the client and store a local temp file for viewing OR I could simply provide an HTTP URI for the document and present it on the device.
My main question is, what is the best way to integrate PDF viewing on the DROID? Can I check to see if they have Acrobat Viewer installed and make a call to the app, passing the URI data to it for loading?
I am attempting to recreate the same functionality we provide on our website in our mobile app.
Not always a good idea.
Just my thoughts here, is there a reason that it must be PDFs delivered to the device? PDF is a very poor format choice for mobile devices. There is no native compatibility for the format, they are most often laid out for print document sizes, and they do not support text reflowing. Viewing PDFs on a mobile device is more of a chore than a helpful function.
If you are looking to embed the PDF as a view in your application, then you can try this vudroid.
I have been using this by including this project as a library and some minor tweaks to the library.
They have provided a PDFView and a service which renders the view.
Works for me; a bit slow though.
Hope that helps.
I have some data in my app that consists of text and image. I want to allow my users to be able to print that data.
Here are the options that I am thinking of:
1) Convert data into HTMl format and allow users to email and they can print from their desktop. This will be zip file with html and images. Pros: can be easily coded. Cons: not sure if users will know what to do with zip file.
2) Convert to PDF. But I have read on forums that iText won't work on Android. So any other options to convert to PDF? Pros: PDF can be easily printed. Cons: have to figure out a way to convert to PDF.
Anybody has tried allowing their users to print data? What are the options
There is an Android app called PrinterShare that allows you to print from the phone, but I think that just prints whole documents.
To do this yourself you would want to have some sort of server on your desktop machine which uses the Java Printing API to send your document to a configured printer. I am just brainstorming here... there are a lot of details to fill in. :-)
Good luck and I hope this helps a little.