I would like to make an app that periodically, sporadically and automatically downloads some data from a list of user-defined sites, so it can then analyze and show historical graphs and other reports based on that data.
If I were to do this in Windows, I'd use the system Task Scheduler; if I were in Unix, I'd use cron; if I were in Android I'd use services. I would like to know how to do it in iOS.
As far as my research goes, this is not trivial in iOS, as there is no public interface for doing this. There are however, some workarounds to get this done:
Pull the historical data when the app awakens: Not possible, because I am not the provider of the data, and most of the data providers I will support don't store or offer access to historical data.
Download the data myself and have the clients pull it when awakening: Not desirable. Not only this requires additional costly infrastructure on my side (which would mean charging my users for what I intend to be a free app), but also some of the content providers require login credentials. I'd rather not ask for my users' login information to access information they can get themselves.
Save a timestamp from the last update and download data when the user puts the app in the foreground if the timestamp is expired: This doesn't serve my purposes, because data may (and is expected to) rapidly change in time. The entire purpose of this app is to automatically download this data periodically so all the historical data is available once the user opens the app again.
Use local notifications: It's pretty much the same as before. It requires user interaction to start the app, and the entire point of the app is to get this data even when the user is not using the device.
Use push notifications: Since these are just notifications that require user interaction to awaken the app, they can't be used for the same reason as local notifications. It seems you can process all pending push notifications once the app awakens, but I read you can't define custom fields for these notifications though.
Use background tasks: This technically seems the most promising of all options, but this is only available for very specific types of apps. I guess that a "Newsstand app" is the closest I can get, and it is actually meant to download data in the background. However, as it is named, it is meant for downloading "magazine or newspaper issues". Whether what I want to do can be classified as this is completely up to the app reviewer, and I'd rather not make an app that may get rejected on a technicality.
So, my question is: are there any other ways to do this that I am not aware of? Are there any apps that already do something similar?
Your assessment is correct. Your only 2 options are to host your own service that periodically downloads the data (your second bullet point) or use Newstand. For Newstand, it's possible that your app could fit the definition; it may just depend on how you characterize the app.
Your only choice in iOS really is to go with server-side infrastructure. Don't be afraid of charging the user; if the service you're providing is really useful, people will pay. I do get that it's a lot of extra work, etc, but it really is the only way.
Newsstand apps can only download data once a day, and they still require s server-side push notification to start the download, so you would have to put some infrastructure in place. More importantly, though, Apple is actually quite strict about being in the newsstand; I've been thru this a few times: you don't necessarily have to be a magazine/periodical, but your app should be primarily used for content distribution.
I think you have one further option, location based updates, but this depends on your users moving around regularly.
See e.g. http://blog.instapaper.com/post/24293729146 and http://blog.news.me/post/21643399885/introducing-paper-boy-automatically-download-your-news
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a software engineer intern for a manufacturing company and they want me to develop an application for the company. They are leaning towards a web application however, I wish to know whether a desktop application would better fit the job. Therefore, I have been googling and looking through stackoverflow to find out what the pros and cons between desktop applications and web applications are. The following is essentially what I found:
Quick disclaimer, I have background in C# and WPF so I am a bit biased as it would be easier for me to develop a desktop application. I have no web experience so there is nothing I can really talk about in that area which is why I wish to know more about whether this application is better suited as a web application or desktop application. I am absolutely open to learning Php and web development to expand my abilities. I have started (a bit) looking into developing the web application using Php7 with Laravel framework.
Pros of desktop applications:
Typically faster than Web Applications (Assuming web application will perform complex queries, calculations, etc, and not just display markups)
Development of GUIs is faster
More secure as desktop applications are private by default.
There are more available controls allowing for a more rich and interactive experience for user (Or at least, these controls are easier/faster to implement on desktop based applcations compared to a web-based application)
Can take advantage of user hardware.
Cons of desktop applications:
Use/deployment is limited by system (However, this should not be a problem because all our systems are Windows based.)
Updates and installation must be manually implemented.
If every client desktop gets a database connection, scaling is not
good as database suffers from heavy load. (However, this probably
will not be the case since we won't have more than 500 users).
Pros of web application
Cross platform (No need to deal with different operating systems) so it is easily portable
Development is quick and easy
Deployment is easy as updates are automatic and server side.
Large community support and available frameworks.
Cons of web application
Larger overhead (Applications tend to be slower due to need to transmit data across the internet).
Need to deal with different browsers. Javascript most likely needs to be tweaked to be perfect on one web platform (Chrome, Firefox, etc) and will not be perfect on the others. (However, this is not that big of a deal).
Security is an issue since data will be public.
Please let me know if any of the above is outdated (most of the posts I found were from 2011 or prior) or wrong. Also, if there is any other pro/con to consider.
Moving on to the application description....
Background on the company: We build and process dozens of different parts every day. For each type of part, after X amount of the part is processed, a sample needs to be taken for inspection. So for example, part Y has 3 samples taken every 120 minutes to be inspected (Because the machine typically finishes processing X amounts in 120 minutes). The inspection results (measurement data) are then stored in the database (MySQL database).
General summary of the application's purpose:
View the schematics of all the parts we design (We store all the schematics as pdfs on a network drive, so this is simply just pulling up the specific pdf requested from the drive and displaying it onto the application).
View/update the status of all the machines in the company (What parts are they working on, are they online/offline, etc). A certain user (Inspector) will use this application to update machine status/information. Then another user (Operator) will use the application to view the statuses.
Monitor part inspections. So, for every machine and part being processed, there will be a timer to let a Operator user know when a certain part needs to be submitted for inspection. Upon part submission, an inspector will then receive a notification to inspect the part, and after letting the application know that they completed the inspection, the timer will restart to let the operator know whens the next time they need to submit a part.
The application will calculate statistical data (For example, Cpk values) from the part measurements obtained from inspection results and display the statistical data along with a graph/chart.
I hope I explained all of this clearly enough. Some other things to note, from my understanding, the users will not need remote access. This application will pretty much only be used on company site. Also, the original reason that the company wanted a web application was because operators will be using a tablet for the application and the tablets they acquired were original android based. However, they decided to switch to using Windows Surface tablets so WPF applications are now a possibility.
With all of this being said, I am really looking for input on what route people with more experience would recommend. I am still in college so please forgive my lack of knowledge/experience. What else should I be thinking about when deciding between a web application and desktop application?
Here are some of the pages I have seen while pondering this topic:
Advantages of web applications over desktop applications
https://www.quora.com/How-much-different-is-it-to-build-a-web-application-vs-a-desktop-application
https://www.quora.com/What-are-the-advantages-and-disadvantages-of-web-based-application-development-vs-desktop-application-development
There were more stackoverflow pages but the one listed above pretty much has everything that the other pages stated.
EDIT: Seems like web-application is winning so far (Not that I mind at all, I am actually excited to develop a web-application based off what I am hearing). Is there anyone who would rather do a desktop application? If so, why?
I'm inherently biased against web apps. They're difficult to get right due to browsers, they're typically insecure (by accident though). The platform sucks (JavaScript and the bazillion libraries from random people/orgs), "everything is a string". I could go on.
However it's undeniably the best platform for reaching a wide, public audience and allowing continual updates.
In a corporate environment the advantages do tend to go away, but not entirely. Updates, for example can be achieved generally by storing all your .exe & DLLs in a shared directory. As you say, you can build a much richer UI quicker and cheaper using the Windows platform.
With regards to your architecture, something that has worked for me in a similar situation is to have a Windows front end, but also have the guts of the business logic, data access (connection pooling) and processing off on a stateless web server (or two) accessed from the UI via Web Services (protocol of your choice - I prefer SOAP due to WCF and WSDL but plenty of folks won't).
This allows for centralised data access and a place to put your one-off batch jobs or calculations that can then be shared. It also has the advantage that if you need to do something really intensive, not every client machine has to have that capability.
Your situation seems to fit this model but without a lot of insider knowledge it's primarily opinion, but possibly one to consider.
Sounds like assembling or similar company work proccess monitoring to me.
If i have to build this application then first i will search and do some research if the function you want is possible and easy to develop with the programming language you will use
for example, if i choose to develop using web based then :
Larger overhead (Applications tend to be slower due to need to
transmit data across the internet).
you can use intranet and good spec server computer
Need to deal with different browsers. Javascript most likely needs to
be tweaked to be perfect on one web platform (Chrome, Firefox, etc)
and will not be perfect on the others. (However, this is not that big
of a deal).
then set the standard browser for working in your workplace
View the schematics of all the parts we design (We store all the
schematics as pdfs on a network drive, so this is simply just pulling
up the specific pdf requested from the drive and displaying it onto
the application).
you can upload pdf to server and view it within browser using pdf viewer plugin like pdfjs or similar plugin
View/update the status of all the machines in the company (What parts
are they working on, are they online/offline, etc). A certain user
(Inspector) will use this application to update machine
status/information. Then another user (Operator) will use the
application to view the statuses
is the machine have ip ?
can i use ping function to the machine to determine the machine is online or not to ease the task ?
if not then what is the schedule of the inspector to inspect the machine ?
of course the inspector can login to the system then update the machine status manually using web application
Monitor part inspections. So, for every machine and part being
processed, there will be a timer to let a Operator user know when a
certain part needs to be submitted for inspection. Upon part
submission, an inspector will then receive a notification to inspect
the part, and after letting the application know that they completed
the inspection, the timer will restart to let the operator know whens
the next time they need to submit a part.
this one sounds like scheduling mechanics to ensure the quality, you can make a timer with jquery and using ajax to send notification to the operator with specific data about certain part that need to be inspected
The application will calculate statistical data (For example, Cpk
values) from the part measurements obtained from inspection results
and display the statistical data along with a graph/chart.
this one is depends on your statistic formula, you can use highchart plugin for this one
the second one after you ensure your choosen programming language able to accomplish the task you want is to design the database structure
Quote by Linus Torvalds :
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Have a nice day, good luck with deciding after give it some good thinking to avoid development problem in the future
Say I created a winform app and distributed to anonymous users, and I want to have a way to get the statistics of user opens the app, one way I can think of is opening a webpage (lightweight) on app startup then analyzing how many times the webpage is opened.
Any other ways to get the statistics?
The best way is to use the existing tools out there and implement them in your application for statistical usage and analytics for example as mentioned before: EQATEC.
you also have Preemptive analytics: http://www.preemptive.com/products/runtime-intelligence/overview
This is a most common used tool especially in the whole ALM lifecycle process and how applications and companies progress onwards with minimal effort story.
you also need to know exactly what kind of statistics are you monitoring here? number of times your app is run on a particular version of the software? particular screens being used within your app? memory/CPU usage? etc...
you also have trackerbird:
http://www.trackerbird.com/
There are many ways.
The initial idea of having your application "phone home" to count its usage isn't that bad, but it does not have to be an entire web page.
You could just post some data to a webservice.
If it can't connect to your web service, you could store the information locally and send it next time the app starts with a valid web connection.
If you do this asynchronously, it should be hardly noticeable when you start the app.
You can have your own tracking service, which you can consume every time when application starts. Alternative way you can use any third party application/service which provides this kind of functionality. Telerik eqatec analytics could be one of its kind.
I am new to GUIs, and i have encountered a problem in my client-server program.
My program is like a "customer-support", where multiple clients can use it from different computers simultaneously.My problem is that when one client changes some info, its inserted into the db but the other client will not see it unless I add a "Refresh" button to my gui.
I want the gui to be dynamic and react to different clients actions. How can you come over this issue?
EDIT:
1. .net4,
2. sql-server,
3. The actions happends after a button click
Basically, you have two options: push or poll. Push (some central server announcing the change to all the listeners) is more immediate, but demands suitable infrastructure. It also depends on the number of clients you need to support, and how many events are passing through the system. Personally, I'm a big fan of redis pub/sub for this (it is actually what we use for the live updates here on stackexchange, coupled with web-sockets). But in some cases you can get the database to provide change notifications directly (personally I prefer not to use this). You may also be able to use events over something like WCF from a central app-server, but that depends on there only being one app-server, which doesn't sound like a good idea to me.
The other option is polling - i.e. have the application automatically query the system periodically (every minute perhaps) to see if the data being displayed has changed. If you can, using the timestamp/rowversion is a cheap way of doing this.
Scenario
I've written a distributed application in C# using WCF.
It uses Client/Server architecture, implementing the Publisher/Subscriber design pattern for "pushing" new data to the client.
The server-side is hosted in a windows service, the client is a windows forms app.
The server-side continually loops through a series of processes and sends the results to the client.
I want to add a whole area to the application for monitoring everything that is going on server-side.
Problem
Here is where I am a bit stuck - I can't decide how I should monitor this stuff.
Thoughts
Do I create an object for storing lots of different information - logs of where the process is up to in the loop on the server-side, exceptions if any, errors etc??
I guess the real question is, how can I successfully maintain a monitoring aspect of the application that gives me relevant information?
Perhaps a central cache on the server-side that gets "snapped" at a point in time every so often and updates the client with the info?
Do you want to know what's currently going on in the server or do you also want to keep a history of what has happened?
If you only want to know what is going on at this moment, my solution would be to maintain the current server state in-memory (this shouldn't be too hard) and have the monitoring client call the server when it wants to know what is happening.
If you want to keep a history of what has happened, you need some data store where the server can write events to. The monitoring client can then read this data store to show what is happening now and what has happened in the past. Even better would be if the client did not have direct access to this data store but instead contacts the server to obtain the relevant information. This way you hide the implementation details of your monitoring history from the client.
We are developing a Windows Forms application that will be installed on about 1,000 employee pcs. Users may run multiple instances of the application at the same time. The clients are all on a single intranet.
Changes in the application may cause database record changes, which in turn must be communicated to the other clients so their UIs are updated.
Our team has talked about two different approaches:
1. Multicast packets
The source client modifies the records and then sends out a multicast packet with a payload that something has changed. The other clients receive this and fetch the data specified. We need to account for the cases when the packet is not received, falling back onto actively retrieving the data.
My question at this point is how does a client know it didn't receive a packet? (don't know what you don't know) Which brings us to some sort of event log with timestamps in the database, and UI controls track the last time they were updated. They come into focus, check their timestamps, and update as needed.
Someone else said the UI elements would just reload every time they come into focus (think modes in outlook, bringing controls to the front of a stack workspace with CAB). And that the multicast is to update the clients that their current context has changed. If they miss it they work with stale data until they change modes and come back.
2. WCF and Callbacks
Clients register with WCF contracts for callbacks over a tcp binding. The primary technical concern with this is the server maintaining many open sockets. We have read up on how it isn't open in the traditional sense, it is put to sleep for a maximum of 90 seconds and then re-established at that point. We also read about the maximum number of open connections a Windows 2003 Server machine can handle, and how to modify that in the registry.
If we have 1,000 open socket connections to a server is this going to fall apart?
If anyone has faced this same situation and tried or evaluated the WCF approach we would love to hear about it.
I have not implemented a situation like this. However, I would think that one of the duplex bindings would not necessarily have a high overhead.
It all depends on how much information the server needs to send back to the clients. I understand you said the information will be used for them to update their UI. However it seems possible that they may not all need the same amount of information at the same time. For instance, if information about the Western region has changed, all 1000 clients may want to know that there is a change, and they may all want to update summary-level information about the Western region, but perhaps only 1/4 of them may need to see the details of the change.
If this is the case, then I'd recommend that the callback only provide information about what has changed, mostly at a summary level. Let those clients who are interested in the details of the change ask for the details. You might even go as far as to provide all the details for the top one or two levels of hierarchy, then for the rest, just include information saying "this changed at time". That way, depending on the level of hierarchy being viewed by a particular client, the client could then ask or not ask.
If necessary, you could batch updates together. If the clients only need to be updated once per second, then you could accumulate the changes for the last second and send them all at once.
You may also want to use some of the Peer to Peer bindings for some tasks. Perhaps the clients in a particular area of your business would like to know a little about what each other are working on - that sort of thing.