I've got an OS X app that I'm distributing outside the App Store. Currently, users go to my website and download a .zip file which contains the code-signed app within. It's very important to me that users don't have to register or create accounts to use my app.
My problem is I'd like to build out referral codes into my app as a way to encourage sharing. Ideally the flow would be something like:
User A opens the app and goes to a menu option to get a unique referral link based on a UUID (to avoid collisions).
User B goes to the unique referral link and downloads the .zip, which is a specially crafted version of the app that contains the referral code. Magic referral behavior is unlocked for User B.
I'm not really concerned about users cheating the system since the code is open-source and the app is free. But since the app is code-signed I can't change it at all (and I definitely don't want to go down the rabbit hole of trying to get my Heroku server to inject a referral code and then re-sign the app), but I'm not above sneaky things like adding the referral code to the name of the app, re-zipping it on the server, and then having the app inspect its own name to extract the referral code.
That, of course, is ugly.* Are there other ways I can cleverly add the referral code to the file metadata? Or is there some completely different approach I can take to otherwise achieve my goal? No solution is too hacky!
* Ugly to the user, that is. We're way past the point of worrying about ugly architecture.
How about not zipping the app until the referral link is called. Generate an external file with the code and zip that with the app then redirect to download the newly created archive. This is relatively easy using server side scripting. You can embed the code in the file and name the file consistently every time so that when downloaded, the app looks for the file, extracts the code as necessary and deletes the extraneous file.
After some experimentation, it appears that among all of the metadata present on files, the only field that's reliably set on different systems (since my Heroku servers don't run OS X) and reliably preserved through the zipping process is the touch timestamp.
I haven't quite gotten the code to completion yet but the current plan is to have the server modify the timestamp of the .app before zipping, and then the program inspects its own timestamp to find its referral code.
If that doesn't work I'll probably go with #Jon's solution above.
Related
We are creating a SCORM package (zip) and uploading to our Blackboard test instance and if one developer (will call him Bob) creates the zip and uploads then all everything works great. Myself and one other developer have packaged up the zip and uploaded it and a particular js file gets a 404 ("The specified resource was not found, or you do not have permission to access it") error when we try and run the application.
If Bob sends me his zip and I upload it to Blackboard it works fine and if I send Bob my zip and he uploads it then it fails, so I am pretty certain that is is an issue of the zip creation. I have looked at the zips and they look identical in terms of file structure.
3 questions:
Is Blackboard known to have particular problems with zip details? These do look like valid zip files.
Are there logs in Blackboard that describe the unzipping process that Blackboard uses when it installs a new SCORM package?
Is there a way to look at the deployed files/dir structure of a deployed SCORM package?
I am relatively new to Blackboard so if I missed something obvious I apologize.
I don't know any specifics about Blackboard's SCORM handling, but if your ZIP is smaller than 100MB you can test it for free at SCORM Cloud. They have a really great parser that will alert you if there is anything unusual or malfunctioning in your SCORM package. It will also let you inspect the package contents.
If it's just the one file that throws the 404 or 403, I'd check the security settings on the file. If they're too restrictive, the file may be physically present in your ZIP, but blocked from rendering by the server (hence 403) or maybe even blocked in the initial upload by the LMS (hence 404) due to insufficient privileges. I've had this happen a few times, typically on files that I downloaded from the interwebs (esp via Chrome's "Save As" file menu option) or on files I received from others.
If you're on a Mac and not a Terminal/chmod kind of guy, the easiest fix is to apply the containing folder's permissions to all enclosed items. ("Get Info" on the containing folder, then click the lock at the bottom of the Get Info window, then click the cog drop-down menu and select "Apply to enclosed items".)
We discovered that it was a path casing issue; on one of the machines the working copy of the file in question had a mix of upper and lower case in it's name and the script tag that referenced it had an all lower case path. We suspect, but can't be certain, that the server where we are running on received an update that made the http requests path case sensitive. But it may have been that way all along and one of us devs messed up out file names.
Some time ago, we distributed a toolbox to our users via the MATLAB App Packager, to make it easier to provide future updates, without users having to handle search paths. Now, we wish to distribute an updated version. Usually, re-packaging the toolbox should make a new .mlappinstall file, which asks the user to upgrade. Instead, MATLAB now considers the new version of the app as a unique new app, and installs it again rather than upgrading. Thus, the user will then have the app twice in the Apps pane, one in an outdated version, and one in the new version.
We have been unable to find an explanation for this in the MATLAB documentation nor online. When we install the updated app (so that both versions are present in the Apps pane), further changing it will upgrade it as expected, so unfortunately, we cannot provide a minimal working example, as we cannot reproduce the issue.
The question is this: How does MATLAB establish app uniqueness? The app name and author fields are identical to the original values, and the version number is incremented, so why might MATLAB not recognize that the app is already installed?
When you had that discontinuity, were you re-packaging using the original .prj file by clicking on it in the file browser in Matlab, or did you run "Package App" again and fill in the same properties?
I think the thing that determines the unique identity of the app is a GUID that is generated behind the scenes by the "Package App" wizard. If you open an existing .prj in the Matlab GUI, it re-uses that GUID. If you run "Package App" again you'll get a fresh GUID regardless of what you put in for the various developer-visible app properties.
You can dig around in the .prj and .mlappinstall files to see this yourself. (I couldn't find it documented anywhere either; I just poked around the files and did some trial and error.) The .prj is just XML, and the .mlappinstall file is a zip file with an "Open Packaging Convention" layout. In the .prj, there's a param.guid element containing the GUID. In the .mlappinstall, its in metadata/appProperties.xml in a GUID element.
If you end up with the same problem again, make sure to re-package using the existing .prj file. Or if you don't have it, once you create your new .prj file, dig the old GUID out of the metadata/appProperties.xml from the old .mlappinstall file and copy it in to your new .prj file and I think it'll behave as the "same" app. This will even let you change the name and contact info for your app, and it'll still install on top of older versions.
I am very new to this, Sorry if this is a naive question. I've been through the ruby tutorial for Dropbox API. Still confused on where should I start.
My situation:
I am running a copyshop. And usually my customers either bring their usb sticks OR upload to gmail then download in my shop OR upload to dropbox then print thier docs/pdfs/fotos.
And one day a customer ask me if I know dropbox. I say YES, I know it. And he ask me if it's possible to share a folder with him, then he can put his files into the folder at home, then come to my shop, open it and print, neat!!
But...Other clients also want to use this service, and they don't want their files exposure to other people (maybe private fotos, secret business plan, important letters...etc). The other problem is I want to make those who do not have dropbox also could upload files to my Dropbox folder that they can come and print.
Why use dropbox is because it's free for till 18G. And When the customer comes to print, I can remove the files, so 2-10G will be enough for 1-3 days buffering.
What I am thinking is to implement a website that allows people to upload DOCs/PDFs/Photos and save these files to my dropbox folder.
For people who have dropbox accounts, they will have a folder called copyshop in their dropbox folder, and they drop files as they usually do. And I will have a folder App/copyshop/ , each one puts files in their copyshop folder will appears in my dropbox as a sub-folder under my App/copyshop folder, e.g. App/copyshop/Tom , App/copyshop/Mary ...etc.
For non-dropboxers they can take advantage of uploading to my website, then save it to my dropbox folder.
Is this possible with Dropbox API? From the official statement:
The API provides methods to read and write from Dropbox securely, so your users can bring all their important files with them to your app. Any changes they make will be saved back to all their computers, tablets and mobile phones.
It looks like not a recommendation way to do it.
Thank you! Every reply is appreciate.
if you make a site to upload files there is no need for dropbox, just let them upload to a map that is available in the shop.
To make it safe with dropbox would be a lot of work, i suppose customers don't want their files exposed to others, only suitable for regular customers, for occasional customers the best method i can think of is let them make a public link of a dropbox file and send it to you.
Another drawback of dropbox is that the size of shared files is added to both the the sharer and the shared so you could get in trouble with the limits.
You could also make a script that monitors a public dropboxfolder and immediately on arrival moves the files to a safe location not accessible from others.
I suppose FTP would be better manageable, you could give big customers their own map and password and occasional users a just-write, don't read the upload of others security.
Answer from the dropboxer,
Yes, this would be possible. There are a number of ways you might do this, and the method you choose will be up to you, so I'll just touch on a few.
Without even using the API, you could have your customers enable and use this feature to send you a read-only link to any file or folder in their Dropbox:
https://www.dropbox.com/help/167
This isn't a shared folder exactly, but it sounds like it should be sufficient.
You could use the API to build an app that would essentially do 1, but help them along with it. Essentially, you would have them authorize your app, and then let them select a file or folder, on which you would call /files (GET) (or /shares if that is more convenient for whatever reason) to download or share the files.
Hope this helps!
Greg
I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.
Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.
Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.
Issues that need to be respected or clarified;
Manual build of a single brand via Idiot-Proof GUI (choose a git
branch/tag, specify a certain brand, configure the app e.g.
IAP-enabled, server-domainname, etc - will be written to the
info.plist)
In previous manual tests, setting the executable name in
the plist didn't work? Sorry, have forgotten the exact problem..
perhaps was only an Xcode Debug buildconfig problem, not relevant to
a distribution build?
Code-Signing?!? Can the profile be specified
on-the-fly? Some brands need to be built with the customer's own
profile.
My personal feeling: Hudson or CruiseControl + Xcode plugin.
There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?
And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.
So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?
Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).
IMHO you can resolve all issues using different targets of XCode.
Every target will share the code but it could:
be signing with diferent profiles
use diferent plist: this implies having different names..
use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
Build with one click in XCode.
I hope this helps
An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.
See this script as a starting point: https://gist.github.com/catmac/1682965
Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.