I've tried…
webview + google docs viewer
PdfRenderer
…but each of them has an issue:
is stable but can't change landscape mode. and can't choose initial page.
can choose initial page, and landscape mode, but it's very slow. and low resolution.
Does anyone know of any better options?
it should be open with in app
Frequently, that is not what the user wants.
Beyond that, quoting myself:
The PDF renderer that Mozilla uses for Firefox is
PDF.js. This works with
Android's WebView, but only the modern incarnation of WebView
(i.e., Android 4.4+). It will also add ~2MB to your APK file, in
the form of a few MB of JavaScript that you need to package as
assets. But, it can handle a fairly wide range of PDF files.
The PDF renderer that Google uses for Chromium is
pdfium. However, this
is C/C++ code, not JavaScript.
Bartosz Schiller's AndroidPdfViewer library
wraps Pdfium in a View that handles rendering and standard gestures (e.g.,
horizontal swipes to move between pages). This works well on older
Android versions (I tested through 4.1), but it adds about 5MB to
your APK per CPU architecture. By default, you get six architectures
and 30MB of overhead. With careful pruning of unnecessary CPU
support (see ya, MIPS) and ABI splits, you can minimize the per-APK
footprint, but you wind up with greater deployment complexity.
Related
A work app I am working on is currently being generated at over 300mb, when in reality it should be around 70mb. I'm aware of the changes Android made whereby native libraries were not being compressed but the size of the APK being generated seems extreme to me. Setting extractNativeLibs="true" seems to have no effect either as i've tried this. below link is a screenshot to show what's obviously causing the issue but I'm stuck on what else I could try to compress the file further?enter image description here
The native libraries you're pulling are huge, compressed or not. Just the library libtwilio is taking 85 MB, then it's present for 4 different device architectures so I'm not surprised the total size is around 300MB.
You should be using the App Bundle so that the libraries of only one architecture is sent to each device of your users. This will considerably reduce the size of the APK that your users are downloading (the size of the App Bundle will still be big, but that only affects what you upload to the Play Console).
Note that even with App Bundle, you'll still be around 100 MB per split APK, so make sure that you really need this library. If it's not a core feature of your app, you can also consider extracting as a dynamic feature so it's only downloaded by your app when the user needs the feature. That would further reduce the size of the initial download.
Background
I am building an Optical Character Recognition (OCR) tool that makes sense of photographed Forms.
Arguably the most complicated part of the pipeline is to get the target Document into perspective; basically what is attempted in this Tutorial.
Due to the fact that the data is acquired often in very poor conditions, i.e.:
Uncontrolled Brightness
Covered or removed corners
Background containing more texture than the Target Document
Shades
Overlapped Documents
I have "solved" the Problem using Instance + Semantic Segmentation.
Situation
The images are uploaded by Users via an App that captures images as is. There are versions for the App in both Android and IOS.
Question
Would it be possible to force the App to use the Users' mobile phone Documents mode (if present) prior to acquiring the photo?
The objective is to simplify the pipeline.
In end effect, at a description level, the App would have to do three things:
1 - Activate the Documents mode
2 - Outline the Target Document; if possible even showing the yellow frame.
3 - Upload the processed file to the server. Orientation and extension are not important.
iOS
This isn't a "mode" for the native camera app.
Android
There isn't a way to have the the "documents mode" automatically selected. This isn't available for all Android devices, either. So even if you could, it wouldn't be reliable.
Best bet is following the documentation for Building a camera app, rather than using the native camera if special document scanning is essential. This won't come out of the box on either platform for you.
I have a few projects with flash that i'd like to turn into apps for mobiles, I started reading adobe air and i've noticed that it uses back some things like inframe action script, something that I have not done since as2.
Is there a way to load scripts and classes like a normal flash file?
If I have a noncomplicated swf, is there a way to migrate it easily into adobe air for android and iOs?.
I've been struggling to find examples of adobe air projects, does anyone have a tip for this?
It is easy. I have converted 30 games to run on iOS and Android. The biggest problem was that they were in AS2 and had to be converted to AS3 first. If your uncomplicated swf projects are in AS3, and developed using Flash Pro, then just change the publishing output from swf for a web page to iOS pr Android. Android would be easier to start because you don't need to get an Apple developer account, create a certificate and provisioning file. With Android you can create a certificate right in Flash Pro. You test publish on your pc or mac first. When you are ready to test on a device you create an ipa (iOS) or .apk (Android).
Yes, there are a lot of screen sizes out there. But you know how you can create Flash in a web page so that it will resize with the page and keep its aspect ratio? Well its the same on mobile - it will resize to fit whatever mobile screen it displays on. Most likely your game is in landscape orientation. Just keep it that way and test it on whatever device you have (an iPad would be good because that aspect ratio or 1024 x 768). Actually, we kept the stage to 736 x 552 and that fit on any screen out there. On tall (wide) screens like the iPhone 5 & 6 you will have space on the sides, but so what.
Just give it a shot and you'll see how easy it is to write an app for both platforms at the same time. And you don't even have to own a Mac (you only need one to upload your completed app to the store, but you can rent time on one and log into it for 10 minutes to do that.)
There's no "how to" when porting a Flash project to Ios or Android. It's the same technology so it's compatible in theory. You can simply compile and publish and you'll get a Ios and Android app in most cases. Now there's 3 major problems that probably 100% of Flash projects will face when publishing for mobile and in probably 99% of cases those problems might imply recreating the whole thing from scratch.
First problem: Sizing and Density. So many phones/tablets sizes and density, chances are your Flash project doesn't have a single line of code dealing with that and as a result your app won't display correctly across any mobile devices. You'll have to put together a big piece of code to handle that and make sure it doesn't break anything in the original project. Good Luck with that.
Second Problem: Performance and memory management, I'm yet to see a Flash project that doesn't systematically waste CPU and memory constantly. That's no problem for a Flash project except when publishing for mobile: can we still waste CPU power? NO, can we still waste memory: NO. You'll have to go through your entire Flash project and optimize everything to not waste CPU and memory. Once again Good Luck with that.
Third Problem: assets. Did you use a bunch of MovieClip here and there? Well no more on mobile unless you want your app to lag and drain the battery down and make the user experience as bad as possible. All assets have to be optimized for mobile, the right asset, the right type, the right size or else ... lag and bad experience. Here again Good Luck with that.
And this is just a small run down of the problems you'll be facing. You will spend probably hundreds of hours trying to port that Flash project to mobile and at the end it will still be running bad anyway. Chances are you should just start over.
EDIT:
Simple Guidelines:
render mode: usually "gpu" (very efficient with bitmap) but "cpu" is also possible (you get more CPU power but less bitmap display efficiency) and also "direct" if you want to use Stage3D (more complicated).
Display: usually bitmap and only rarely vector. Don't oversize them and don't undersize them either. Reuse as much as possible (saves memory and battery)
Handling sizes and density: scaling your content is the easy way but not the less efficient one, as long as your bitmaps are of good quality you should be able to get a good resolution in most density and size. Because there's so many different sizes out there you'll decide if you want your content to fit any size or to display as much as possible while filling the side gaps. AIR/Flash has no built-in system for handling that so you'll have to create your own or to find something open source out there that can do that. Basically you have a content that is n x n and it needs to display on a mobile screen that is n x n, you calculate the scale factor and scale your content and center it.
perf, memory, battery: reuse object as much as possible. If there's a bitmap that you'll use often don't get rid of it just reuse it. If you reuse you don't need more CPU, don't need more memory and don't need more battery.
how to get perf: displaying something and running code, that's the 2 things that will slow down the app so optimize both and test often. Maybe reducing the quality of some bitmap will boost your perf. maybe optimizing your code in some places will get you a few more fps, etc. This is a per project try and test.
I have created one application which contains several buttons to home page clicking on one of that button my application redirects to some view which contains JQM form, with JQM calendar, text field, buttons and database etc....
My query is that when I test my application in android device on that time application works a little bit slow, even if I have not used any images,or any data which can contain more space. That's my first query and second one is that when I tested my application to android tablet on that time that form page is appearing for a while and suddenly it redirects back to home page automatically, while this same feature working well for android phone.
Why this strange issue?
If any one can guide me on it that it will be my pleasure
It's difficult to make assumptions regarding the slow performance and the redirection issue. Below you can find some aspects which in my opinion affect the performance of a mobile application which consists of HTML5, CSS3, JavaScript and should be taken into consideration on the analysis, the design and the development phase.
Implementation method based on the size
When developing small mobile applications the usage of a single HTML page using internal-AJAX page linking is recommended. For bigger mobile applications, a method of using different HTML pages with internal-AJAX linking is recommended. Try to create reusable page templates.
Page Transitions
As stated in the jQM 1.1.1 Docs, by default, all transitions except fade require 3D transform support. Devices that lack 3D support will fall back to a fade transition, regardless of the transition specified. jQM does this this to proactively exclude poorly-performing platforms like Android 2.x from advanced transitions and ensure they still have a smooth experience. Note that there are platforms such as Android 3.0 that technically support 3D transforms, but still have poor animation performance so this won't guarantee that every browser will be 100% flicker-free. Decide the transition type that you will use after considering the above.
Minify JS and CSS files
Each page should be as lightweight as possible. The minification’s goal is to preserve the operational qualities of the code while reducing its overall byte footprint. There are a lot of tools available on the WEB like the YUI Compressor, the Minify and many more. Furthermore there are tools like the JLint which is used to check whether JavaScript source code complies with coding rules. JLint is a code quality tool which checks for problems in the JavaScript code. The reported problems are not necessarily syntax errors but may be structural problems. Note that JLint does not prove that your code is correct. Consider it as a helping tool. Also there are tools for performing CSS optimization. The optimization helps you to get smaller CSS file sizes and better written code. You can find a lot of CSS optimizers available on the WEB such as CleanCSS and CSSTidy.
Components limits
The HTML pages is recommended to be limited to 25kb in order to gain the optimal caching advantage for the majority of the mobile web browsers. The caching limit varies depending on the OS version. For example Android 2.1 has a caching limit of approximately 2Mb.
HTML5 & CSS3
Try to create easy to read, to extend and reusable code. It is important to take full advantage of the using of HTML5 and CSS3. The HTML5 DocType declaration (<!DOCTYPE html>) should be the first thing in your HTML5 document before the html tag. It is an instruction to the web browser about what version of HTML the page is written in.
Use the W3C mobileOK Checker
The W3C mobileOK Checker is a free service by W3C that helps check the level of mobile friendliness of Web documents, and in particular assert whether a Web document is mobileOK. A Web Page is mobileOK when it passes all the tests. The tests are defined in the mobileOK Basic Tests 1.0 specification. To understand why checking a Web document for mobile-friendliness really matters, it is probably worth emphasizing a few points about the so-called mobile world. Compared to a regular desktop computer, a mobile device may be regarded as limited at first glance: smaller screen size, smaller processing powers, smaller amount of memory, no mouse, and so on. Compared to fixed data connections, mobile networks can be slow and often have a higher latency. Compared to a user sitting in front of his computer, the user on the go has limited time and is easily distracted. On top of these constraints, the mobile world is highly fragmented: many different devices, each of them defining a unique set of supported features.
Consider the appearance on different screen sizes
The screens density and the viewport size and web page’s scale should be taken into consideration when targeting different screen sizes. The viewport metadata can be used to define the viewport size where viewport is the container area in which the page is drawn. The viewport scale defines the zoom level which is applied to the web page. The target-densitydpi viewport property and CSS, JS techniques can be used to change the target screen density for the web page. There are plenty of articles on the WEB regarding the appearance on different screen sizes.
Identify the flows with potential delay
The PageSpeed Firefox/Chrome extension can be used to check the pages speed. When you profile a web page with Page Speed, it evaluates the page's conformance to a number of different rules. These rules are general front-end best practices you can apply at any stage of web development. The extension gives specific tips and suggestions on how to best implement the rules and incorporate them into the development process.
I hope this helps.
Let me explain our situation first,
We plan to develop a web application by using webview component which will work on tablet devices (target device specification: Android 3.0, Dual Core Processor (1GHz x 2), 10.1"WXGA, 1GB RAM).
In the application there will be 2D animations and we design a character. Like,
This character may wear different things, may change mimics
This character may walk with these artifacts (over a fix background image)
Application will use local resources.
My Questions are,
1) Which tools will be best to show these animations considering performance in webview and less resources size.
Canvas
SVG
Pure javascript by using fix images or animated gifs
Or something else? (Note: We do not want to use flash)
2) Which development environment(s), tool(s) do you suggest to construct these animations and related resources?
This is my first post in stackoverflow.
I hope this post and answers may help other developers also...
Best Regards,
Canvas would be better when we count in performance and SVG is something you can't render truly in all of the browsers, coz in previous versions of android SVG is not enabled by default you have to do a workaround on it to get it worked. Canvas is best tool as you can render it in most of the browsers and considering performance in webview. any how android 3.0 onwards ther's a support for SVG.