A client wants a web app for an event and he wants to avoid handling store problems such as validation etc... to go faster.
I already developped some app for android & iOS platform and not really for flutter web.
The client wants to access the app offline, not everything of course but at least some static information and one or two request saved in cache.
I looked for those thing in PWA and it usually use service worker (a pain in the ass to use), so i tried but there si so many element to keep in cache with flutter that it is hard to keep all and impossible to show the page because some element are missing.
So i have 2 questions :
Did someone made a custom service worker and can show his web app offline ?
is there a way to do this differently ? detect if the connection is offline and show the page saved elsewhere (i know about hive etc for example but i don't know if it can work with this kind of cache)
Thanks you !!!
Related
I would like to run code to delete files created on local storage when my flutter app is uninstalled. How can I do the same? Is there any event to handle this? If not, how can I clean up the images generated?I don't see any reference online for this.
If you are saving images to users gallery, that image is no longer the domain of your app, in any way shape or form. If you create a gallery within your app this would be different, also, a gallery within your app would in fact be deleted along with any other memory your app uses. I highly doubt you could access users gallery & delete images even with users permission.
Possible backend server solution: here
This indicates this is not possible as per below:
All of your app's files are deleted by the OS when the user deletes
the app. If Apple wanted developers to have that capability, we would
have that capability 🙂
You could make a case for needing to know the app is deleted if you
are storing stuff on the server side. Currently from the server's
point of view there's no way to know whether the app was deleted or
the user just stopped using it. But locally stored files are not an
issue.
I am also looking for a solution to this & I think server logic will get it done.
Must be some sort of logic possible to discover server side if user is GONE!
I am building an App on Ionic 3.
How many users can ionic 3 platform handle?
Is Ionic 3 scalable to 500,000-1,000,000 users?
The App is a basic Progress Tracking Tool and a user is expected to open it 1-2 times per day for max 5 min.
Thanks!
Whether Ionic can handle it isn't the question here, it depends entirely on the foundations on which your app is built.
If your app requires connections to a single or multiple APIs and a full backend system, it will be how well your server can process those loads.
Each instance of an Ionic application will work perfectly fine if built correctly as they're isolated to the device in which it is installed. It's all the important stuff working in the background to serve content to your app which is important.
To provide a primitive example; imagine a social media app like Facebook or Twitter. Let's assume both apps are built to sensible coding standards. If you were to plug either of those apps in to a server that was essentially a dusty old box underneath someone's desk, the entire system would completely crash. There's no way it could handle all of the requests for information because the technology simply can't process it.
The reason they don't crash is because they have large-scale data centres, capable of serving millions if not billions of requests simultaneously - they have good servers.
Moral of the story:
If you're building an app, arguably for any size but certainly for 500K+ people, start with your foundations first. The foundation is the servers/data points which will serve your app. Build that correct, and your Ionic app will work perfectly fine.
Yes it can.
The app it self is self contained, your backend will be the bottleneck here.
I have recently gone through couple of Progressive Web application(PWA) articles on google. What I have got it it is concept for web application
which combines best of two world i.e. latest browser features(like web workers etc) and native application(speed, home page etc).
I have two basic doubts .
Is PWA applicable for mobile sites only or for desktop based application also ? In the couple of examples I have gone through mainly talks that using
PWA allows the mobile user to user the mobile sites like app without installing and equally good speed.
I understand the point with PWA user does not have to install the native app on his/her mobile but i believe even in case of PWA all content(static content like html,css,jss,images etc) will be stored in cache as user navigates to web application. Service worker checks if content
available in cache it will serve it from there otherwise fetch it from server.
So when PWA caching the content on client side, it will be equivalent
of size of native app. Is n't it ?
Its applicable to both. Think a PWA as a website that gets stored in local cache.
It really depends on what you configure service workers in the browser to do, but the gist of the thing is:
cache HTML, CSS, and JS on the client (usually on a per need basis, load and cache)
use browser local database storage to store data coming from your back end database
use AJAX, and/or WebSockets to get data back and forth from your back end systems
Call it a website, a javascript application, whatever you call it, its just the same old/new browser tricks working with local cache introduced; so it loads offline.
And loading offline is pretty much as close as they come to a native app, PWAs as of today are HTML, CSS, JS applications running on a browser; generically called a website.
Hope its clear.
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
We have a web application and we've built phone applications (iPhone, Android, BlackBerry) to be companions to the site. The usual workflow is that an existing user of the site gets a phone app and then plugs their existing credentials into the phone app and they are off and running, but more often now we are seeing folks who are downloading the app and then (and this should not surprise anyone) don't read the help screen that explains they need to go and get credentials at the web site and therefore cannot connect to the application which does require registration to manage their content. This is a giant usability fail condition.
So we know that we need to put user registration workflows on the phone app.
Other than the obvious solution of duplicating our registration page on the mobile, does anyone know of a better identity solution for the phone? For example, on the desktop we also use Facebook Connect as an identity server and the users love it. I'm looking for something that simple that we can implement across the major smartphone platforms.
Clarifying note:
I should add here that this registration mechanism is likely to; and it would be desirable if it did, go hand in hand with a general identity/authorization mechanism such as the Facebook mechanism mentioned below.
One other place I'm poking around is to see whether there's an openId solution that does not require a browser to pop up.
Restful service might be the e asiest way for you to achieve this, you can use it on any device that can make http requests, so you can make your own login screens and talk to the s ervice that way...
Facebook has a Connect API for the iPhone. Integrating it into your iPhone app is very smooth.
http://developers.facebook.com/connect_iphone.php
On the BlackBerry we were able to build a fairly robust REST pipeline between the client apps in the field and our servers. We primary use the framework for updates, but the device API is generic enough to be able to build almost anything you need via standard HTTP/HTTPS GET/POST calls.
On the RIM platform, look into the HttpConnection API as a starting point. There is also an example on the BlackBerry Developer's site which will help. Finally, I believe there are several examples inside the sample package that comes with every BlackBerry JDE (IDE + API download).