I'm looking at designing and building out a system that would allow A/B testing of different flows in an iOS app (e.g. registration flow, log-in flow, purchasing flow).
A system that comes to mind initially looks like:
app pings server, server responds giving list of resources (which could include some links to xib files)
if the user does not have those xibs on disk, download them and save them to disk
when the view controller is presented, load from the xib if it has been downloaded (else default to the one the app was shipped with)
Does anyone have any thoughts on this idea or any insights on this system?
NOTE: I am not trying to implement a system where I can add new features. Right now, I'm focusing on changing flows, like the text and views a user will see. I'm not looking into a discussion of whether this violates the App Store rules, but if you would like to do so - go for it!
This is possible, but I don't know if I would download XIBs to the device. Seems a little risky to me.
Apple did a talk at WWDC 2010 where they address this exact issue, and they recommend building the interface using (more or less) Plists or JSON to describe the UI elements and their functions, and building up the views dynamically. It's well worth watching as it brings up a lot of smaller issues that aren't immediately obvious, but it requires a developer account to access it).
This would be an interesting system to use. I wonder if one could write a shell script to replace the old binary of an app with a new one. I know it would probably be more complicated then just that, but it would be cool to do. I would definitely use this for in house apps, or personal tools. Its to bad the apple wouldn't allow it, unless someone could secretly slip it past them :-)
I say go for it. You seem to have a pretty good idea of what you want to do and how you want to do it. Changing the UI based on responses from a server isn't uncommon, but I guess downloading xib files from the server is. I don't see why it wouldn't work though and I don't think it would be rejected by Apple, but you never know.
Related
I have been learning coding for about a month now. I have some good experience with Python, and additionally I have completed this web development course on Udacity.
Now, I have a good foundation for programming, but one thing that confused me a lot is how to interact with various websites and APIs. The course I did briefly touched on this in terms of XML and JSON files and how some webpages offer their pages in these formats for easier reading by other machines.
But there are still a bunch of tasks which I have no idea how to approach whatsoever, but want to eventually do. I have constructed some hypothetical examples for the purpose of this question. I will post my current rough understanding of how I would do them below each one, and would appreciate feedback (on the API interaction, not on the front-end or on any back-end algorithms/AI/parsing):
Creating a phone application (disregarding the front-end part) which can then communicate with and perform rudimentary tasks on my computer.
I have no idea how to do this, and my guess would be that I would have to look into some external application/API meant for this process and implement this on both-ends of the system.
Being able to write a bot which goes on to a game website and controls the object via script. (e.g going onto a pacman game website written in flash and automatically controlling the character to avoid the ghosts)
I don't even know if this is possible, or how browser flash games interact handle the user-server interaction. Would I have to post some data via HTTP manually in the same way that playing in the keyboard would do? Or is everything done client side, in which case how would I fake user input? How would I get information on the ghost's position to work the AI?
Creating a mobile app for my school by allowing users to put their username and password into the app and then having the app automatically log in to the school and fetch certain data (e.g timetable) and return back in a readable form.
I'm guessing that I would take the input from the user on my mobile-app, and then navigate to the school's login page and POST this data in the relevant forms to log in. And then that I would (somehow, not sure), navigate to the timetable URL through my code while still managing to stay logged in, and then parse the html there?
I would appreciate some detail on how these kind of things are done, preferably with reference to these examples, so that I can get a better conceptual understanding.
Thanks!
Note: I have asked all those various questions mostly rhetorically, just so that those reading can get a better understanding of what my current programming level and understanding of APIs is at. I do not expect nor require specific answers for each and every question (so I hope this doesn't get flagged as being too vague or requiring too much detail!), I just would appreciate some responses telling me roughly how each of these APIs work approximately and how I would even start at looking at how to do these things.
You asked too many questions and honestly speaking I am not able to read and grasp entire text posted by you.
So, I am focusing only the title of your question:
"A conceptual understanding of API"
API (Application Programming Interface) means a set of functions which you can directly use by simply passing parameters to them.
Actually, in application development there are many common functions which every application programmer have to use. So, instead of coding them every time by every programmer, they are already coded in functions which you can use simply by passing parameters to them (if they need any external parameter).
Example:
I am offering you a maths API, set of functions {add, sub, mul, div}. You can pass two numbers to any of these four functions and get desired result instead of coding every time for ever operation like add, sub, mul and div.
Hope it helps...
I've an iOS app that interacts with a custom API, that in turn interacts with the DB. I was thinking to eliminate the custom API step and access the DB directly from the iOS application (MongoDB).
Now several questions emerged:
It would be a security issue to distribute login credentials (even if they're encrypted) with the app.
I guess due to flaky networks the DB could be corrupted if designed improperly.
Are there any real world examples where a database backend is directly accessed from Cocoa?
Basically it boils down to yes or no - and why.
PS: The database resides on the web, not an intranet/corporate network
There are pros and cons. I think you listed all the cons. IMO, there are no pros other than having one less layer to maintain. However, if you think this particular database will ever be accessed by anything other than the iOS app, you might as well go ahead and do the intermediate layer - you're going to need it eventually. Might as well plan for it at the outset.
I'd look at using a framework like RailsKit to take care of the work.
As a proof-of-concept, we built an app that connected directly with a Rails backend, and the syncing worked well --- except that it was a bit of a pain to make it play nice: the interface would freeze while it waited for confirmation from the DB, etc.
So we're going to use an existing, available framework to take care of that work for us, and focus our development efforts on the interface and user experience.
I have a application that isn't currently a document-based application (because I thought it would be more trouble than its worth). However I've been thinking it may possibly be worth it now, but there is one issue I haven't worked out yet. Sharing NSDocument subclasses between multiple windows.
So do subclasses of NSDocument have to be tied to a single NSWindowController, or can I share these between multiple windows? The reason I ask is my applications files are likely to up 100MiB (or larger) and its also likely that a user will open the same file in more than one window. Also these files take a relatively long time to process, so allowing multiple windows access to the same NSDocument would be excellent. Also, the files are updated very quickly with lots of data, so synchronizing multiple instances of the same document would use a lot of CPU time.
Has anybody done this, or can it even be done with a Document-based application? Any advice on this topic is greatly appreciated.
You should be able to use the method - (void)addWindowController:(NSWindowController *)aController found in the NSDocument Class Reference to do just that. There will be a lot of logic to let it know where to send what data, but this will at least give you control over several window controllers linked to the same document
So far this is the best answer I've found, which doesn't directly answer the question, but deals with many of the same obstacles I'm facing. Hopefully someone else has a better, more detailed and direct answer for me.
http://www.cocoadev.com/index.pl?DocumentBasedAppWithOneWindowForAllDocuments
The Document architecture wil help you to manage multiple models - ie. if you want the user to have multiple models open simultaneously and be able to switch between them, it could be of benefit to you.
It doesn't stop you from doing anything, it doesn't make otherwise easy things difficult. Handling the Windows and GUI is still down to you, and if you are unsure how to structure this, it wont make any difference if you use a document or not.
If the contents of a window can change over time to represent different documents - what happens when many documents are open? This can be a difficult problem to solve, and i don't really mean from a technical point of view (changing a window's contents is as easy as window.contentView=newView, right?).
It sounds like you have many misconceptions about what the document architecture is and what it can do for you.
The default is each document has one dedicated windows controller. But you can override
- (void)makeWindowControllers
to create your own windows controller and add them to the document as Slev mentioned.
I'm interested in picking up some tips and tricks while learning about the SDK. What I am looking for something that you wish you had known getting started that would have benefited you now.
don't use a DOM parser, but a SAX parser. (Memory issues / speed).
if you use custom table cells, don't add too many views. (Slow scrolling issues)
if you add views to table cells, like labels, you may want to make their background opaque.
the generated table view code defeats the MVC paradigm. Think about your data model, and implement an UITableViewDataSource. Really.
One of the things I wish I knew at the very beginning was how to download data in a non-blocking way, specifically using NSURLConnection. The first versions of my apps suffered somewhat because I was using things like dataWithContentsOfURL:, which isn't a great idea on the iPhone, since you're never really sure what the network environment will be like for your users. To make it worse, I was testing over a fiber connection at home with an iPod touch, when a large number of my users were using Edge on their iPhones.
If you want to use SQLite, go with either Core Data (available in 3.0) or FMDatabase (Flying Meat). My first two apps, I wrote a customer wrapper and bound directly to SQLite. I am currently using FMDatabase with a new application and have found the experience much nicer.
In the case of a lot of developers, including Google, I'm sure they wish they knew their app would be rejected once complete.
CoreData Bindings is not supported on the phone.
Use the Clang Static Analyzer
http://clang-analyzer.llvm.org/
It's great for finding reference counting issues -- I have never seen a false positive.
Regarding the table view speed check out Loren Brichter's blog post http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-with-uitableview/
One of our next projects is supposed to be a MS Windows based game (written in C#, with a winform GUI and an integrated DirectX display-control) for a customer who wants to give away prizes to the best players. This project is meant to run for a couple of years, with championships, ladders, tournaments, player vs. player-action and so on.
One of the main concerns here is cheating, as a player would benefit dramatically if he was able to - for instance - let a custom made bot play the game for him (more in terms of strategy-decisions than in terms of playing many hours).
So my question is: what technical possibilites do we have to detect bot activity? We can of course track the number of hours played, analyze strategies to detect anomalies and so on, but as far as this question is concerned, I would be more interested in knowing details like
how to detect if another application makes periodical screenshots?
how to detect if another application scans our process memory?
what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
what other ways exist in which a cheater could gather informations about the current game state, feed those to a bot and send the determined actions back to the client?
Your feedback is highly appreciated!
I wrote d2botnet, a .net diablo 2 automation engine a while back, and something you can add to your list of things to watch out for are malformed /invalid/forged packets. I assume this game will communicate over TCP. Packet sniffing and forging are usually the first way games (online anyways) are automated. I know blizzard would detect malformed packets, somehting i tried to stay away from doing in d2botnet.
So make sure you detect invalid packets. Encrypt them. Hash them. do somethign to make sure they are valid. If you think about it, if someone can know exactly what every packet means that is sent back and forth they dont even need to run the client software, which then makes any process based detection a moot point. So you can also add in some sort of packet based challenge response that your cleint must know how to respond to.
Just an idea what if the 'cheater' runs your software in a virtual machine (like vmware) and makes screenshots of that window? I doubt you can defend against that.
You obviously can't defend against the 'analog gap', e.g. the cheater's system makes external screenshots with a high quality camera - I guess it's only a theoretical issue.
Maybe you should investigate chess sites. There is a lot of money in chess, they don't like bots either - maybe they have come up with a solution already.
The best protection against automation is to not have tasks that require grinding.
That being said, the best way to detect automation is to actively engage the user and require periodic CAPTCHA-like tests (except without the image and so forth). I'd recommend utilizing a database of several thousand simple one-off questions that get posed to the user every so often.
However, based on your question, I'd say your best bet is to not implement the anti-automation features in C#. You stand very little chance of detecting well-written hacks/bots from within managed code, especially when all the hacker has to do is simply go into ring0 to avoid detection via any standard method. I'd recommend a Warden-like approach (download-able module that you can update whenever you feel like) combined with a Kernel-Mode Driver that hooks all of the windows API functions and watches them for "inappropriate" calls. Note, however, that you're going to run into a lot of false positives, so you need to not base your banning system on your automated data. Always have a human look over it before banning.
A common method of listening to keyboard and mouse input in an application is setting a windows hook using SetWindowsHookEx.
Vendors usually try to protect their software during installation so that hacker won't automate and crack/find a serial for their application.
Google the term: "Key Loggers"...
Here's an article that describes the problem and methods to prevent it.
I have no deeper understanding on how PunkBuster and such softwar works, but this is the way I'd go:
Iintercept calls to the API functions that handle the memory stuff like ReadProcessMemory, WriteProcessMemory and so on.
You'd detect if your process is involved in the call, log it, and trampoline the call back to the original function.
This should work for the screenshot taking too, but you might want to intercept the BitBlt function.
Here's a basic tutorial concerning the function interception:
Intercepting System API Calls
You should look into what goes into Punkbuster, Valve Anti-Cheat, and some other anti-cheat stuff for some pointers.
Edit: What I mean is, look into how they do it; how they detect that stuff.
I don't know the technical details, but Intenet Chess Club's BlitzIn program seems to have integrated program switching detection. That's of course for detecting people running a chess engine on the side and not directly applicable to your case, but you may be able to extrapolate the apporach to something like if process X takes more than Z% CPU time the next Y cycles, it's probably a bot running.
That in addition to a "you must not run anything else while playing the game to be eligible for prizes" as part of the contest rules might work.
Also, a draconian "we might decide in any time for any reason that you have been using a bot and disqualify you" rule also helps with the heuristic approach above (used in prized ICC chess tournaments).
All these questions are easily solved by the rule 1 above:
* how to detect if another application makes periodical screenshots?
* how to detect if another application scans our process memory?
* what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
* is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers, only sending to and receiving updates from the clients, that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place). That, and actively monitoring for new weird behavior found might get you close to where you want to be.