It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Some software has the option to collect anonymous usage data. How does that work? How is it collected and sent? I'd like to write a small test to try this myself, but I'm not sure where to begin.
Collecting data: You can accumulate whatever data you want to accumulate. For example, we wanted to know what forms our users were using (we have a lot of forms). So, in every form's FormCreate, we call code that appends Self.Name to a text file. Now we are tracking form creations, and the order in which our users visit the forms.
You could collect any data you wanted. For example, if you wanted to know how many times a user got a certain error message, whenever you show the error message, append the name of the error message to a file. If you wanted to know how long a user spent on a certain screen, you could note Now() when the form is opened and Now() when the form is closed and then write the difference to a data file.
Sending the data: You need to transfer either the raw data you collected to your server or you need to pre-process that data and send that. In our example above, we would just send the text file. You can use any internet library of your choice to upload a file to your server. We use Indy FTP, since it comes with Delphi. Upload the file, giving it a unique name (maybe a GUID if your server accepts that format?) to your server. (Choosing a good file name that hasn't already been uploaded to the server by another user's application is one of the challenges you'll have.) Be sure that you don't include anything in the file or file name that could be used to identify the user unless you've gotten permission to do so & understand any legal ramifications. Decide you want to upload the file maybe once a week, or once a day at a random time so all users aren't uploading at the same time. Of course you might want to pre-process the file before uploading it, collapsing the data in some way to make the file smaller.
Be sure your data collection file doesn't grow too big. You probably should delete it after uploading it. Also, if the upload file is big, it will cause a noticeable delay and freeze in your application unless you take steps to upload in the background, etc.
Note that if your users have very strict firewalls or security software, sending a file like this might be prohibited and could even cause your software to be flagged as malware. You'll need to carefully consider this issue and evaluate the various ways that data can be sent over the web in a way that is safe, unobtrusive and ANONYMOUS, and allowed by various security applications. For example, you will need to understand whatever protocol you use to upload and how much information that it might provide your server about the identify (like IP address, which might be vaguely personal with the right tools or search warrant.)
Then, at your server, over weeks (or whatever time frame you choose to upload files) you will have a lot of files that your software uploaded from users' machines. These files contain the names of the forms your users loaded, or the names of the error messages they got, or elapsed times, or whatever data you collected and uploaded. You would then decide how to process that data into a meaningful reports. Examining all the files, you might learn something like: 50% of our users never opened form X. Or: most users never saw error message #17 or only got error message #22 on form TForm3, or users spent an average of 45 seconds with Form4 visible.
I've simplified almost everything above. There are of course, for example, much better ways to save the collected data than appending to a text file. A text file might grow too big and too slow. There might be legal or ethical issues you'll need to consider.
But this is the general idea.
This is not a casual project to put into an application that others will use unless you fully understand all the issues and design and code it well. (That, I suppose, can be said about any coding!) But, as I noted, above I've written an overview of how you might do it for, say, an homework assignment or to just explore.)
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 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!
I'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.
I've come to a crazy idea to use Google event tracking in Delphi desktop application. I want to track users behaviour workflow to make application better. But it's in javascript.
Is it possible somehow to do it directly from application? Or do I need for example to make a webpage which communicates with Google event tracking API and application sends REST queries to that webpage?
Or maybe I can do it without javascript at all and directly from application?
You should be very careful with this, and warn your users.
Though software running locally is a different thing than software running from a web-site in a browser, the interconnectedness of software is increasing. So is the general feeling in the public on what is right and not to communicate.
For instance, a lot of software 'phones home' to check for the latest version without even asking permission to their users. I can understand that some users have a problem with that, but it indicates the general opinion on this is shifting. The vendors can track usage statistics based on that 'phone home' alone.
I'm not sure if the Google Event Tracking would be the best way to solve usage tracking from a desktop application, but the general idea (collecting usage statistics and error information) can work out very well.
Software from big vendors have been getting usage statistics from their software for years, and they ask their users up-front if sending statistics is OK, and at the time of an error, each time ask them if that is OK too.
In fact the book "Why Software Sucks ... and What Can You Do About It" and presentations from David Platt explains really well how to do this and how to communicate this to your users.
You need to do this in a very anonymous way, and you can because basically you are interested in these things:
what is the largest percentage of errors
what is the largest percentage of features used
what is the smallest percentage of features not used
As long as you communicate percentages, it is clear to explain to your users that the data will be very non-specific.
On the other hand: being able to focus on the actual errors can improve your software a lot.
The errors communicated back to you can contain much detail, so you need to either strip that detail out, or be very upfront with your users indicating which details are being sent to you when communicating individual errors.
--jeroen
I developed my own solution (I called it 'softmeter') to do exactly this. It is a dll that will do all the REST queries to Google Analytics.
There is sample Delphi code that wraps the DLL in a Delphi class so sending an event is simple as
dllSoftMeter.sendEvent('Conversion events', 'Donate clicked', 1);
If you do not mind using 3rd party libraries, you can use it.
In fact I found that most software using it, is Delphi made software.
Here is a more extended sample of the Delphi code for the implementation.
https://www.starmessagesoftware.com/blog/track-delphi-pascal-gui-application-google-analytics
You will need of course to get consent from the end-user.
First of all, I'm not a hacker :)
We're doing a project where we'll award points to users for visiting certain groups of sites.
Obviously there are major privacy concerns, but we have no interest in actually knowing where they've been, just as long as the program we create can check the history and through an algorithm, rank the site/user.
This would be a downloadable application and we'd tell the user how it worked, since transparency is vital.
Now, with that in mind, is there a way for a local program to access the Cache/History of a browser and make a list out of it?
I've read that Firefox uses SQLite to compile their History, which could potentially be parsed using Adobe AIR.
At the same time, Adobe AIR has access to the filesystem, so it could probably check if the usual IE temporary folders have any files stored. If so, try to read the URL they were downloaded from?
I know all of this sounds very dodgy, but try to keep an open mind :)
Thank you all for your help.
Not a full answer to your question, but you might be interested in the CSS History hack. If you already KNOW the sites you want to rank, you will be able to find out which sites the users visited.
Good thing you said something about a LOCAL program, because there are surely ways to read out the SQLite database from Mozilla and IE's history and you can find plenty of implementations using your favorite search engine.
Particularly easy to use are Nirsoft's utilities MozillaHistoryView and IEHistoryView which you could script to output CSV and parse that file afterwards.
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 8 years ago.
Improve this question
I'm working on a piece of software that creates a contract and captures the client's signature via gif and applies it to the contract (and spits out a pdf). Now, we're storing the data from the contract but when it comes to the signature, I'm not sure if I should.
Store it:
Pros: If the pdf document is lost, I can reconstruct the document instantly and easily for whomever needs it (us or client). (checked with the lawyers, reconstructing the document from data is legal and applicable as long as no data is or has changed)
Cons: Although I will never do anything with the stored signature, I can't be certain that, if I ever leave the company, my coworkers or replacements will honor that.
Don't Store it:
Pros: Ethical high ground, there's no option for anyone now or in the future to use that image and do anything with it. It keeps everyone honest.
Cons: Now there is no way to reconstruct the original document if the pdf is lost - which is a good possibility.
Talk to a lawyer.
If it's grey enough an area, I'd vote for don't-store-it.
Lawyers are the most important people to talk to in this case.
But I'd still say don't store it.
If necessary, I'd suggest storing the contract in a format from which you CANNOT extract the original GIF. Such as taking a png file for the whole document, or some other solution.
However, if you are storing the whole document with the signature embedded (and not extractable) then you have your ability to resend the signature, and you have no reason to store the unattached GIFs.
Ultimately, having the unattached GIFs is just providing an enormous opening to getting sued.
Storing them that way also opens you up to problems relating to 'pasting the wrong GIF' into a contract.
I would say that having the gif files in a way that does not EXPLICITLY bind them to the ONE contract they apply to is VERY dangerous.
EDIT
After reading your post again I would say that there isn't a point in storing the GIFs or the PDFs. You should have a hard copy somewhere of the signed document (and if you are losing hard copies of contracts, then there are SERIOUS organizational issues) and after that, you don't need the signed version anymore, you just need to know the terms of the contract. So as long as you can reconstruct the terms for reading over, then I don't see why you'd need the literal signature again. If you need to prove they signed it, go back to the hard copy.
Do you need to keep the signature for anything else? If not I'd store it only for as long as is required to produce the PDF, as there is no reason to keep it around.
In New Zealand the collection of personal data is governed by the Privacy Act and as such one of its requirements is the data is only stored for the length of time required for the reason the data was collected.
The signature can still be extracted from the PDF. So whether you store the original GIF does not seem to make a difference, security wise.
How about this for thought:
If it was an electronic signature, you would probably not be able/allowed to store it at all. You could store the signature+document (i.e. the crypto-signed hash of the initial document) and verify it with the public key, but to store a lot of client's private keys to be able to re-sign documents.
Imagine some one breaking in to the database and stealing those private keys (gifs or RSA/DSA keys). That store would be very useful/profitable to a criminal organization.
Do you want to expose yourself to that?
I don't know, a GIF can be re-created by anybody with a copy of the document and a scanner...not storing you lose the benefit of having it, without any real security value being added....
I would get legal advice on some text to place near the signature in the final document. Maybe something like:
John Hancock http://rightzinger.com/LibraryofProgress/FoundingFathers/John_Hancock_signature.gif
(electronically added signature)