All you ios architects out there, please help me choose architecture/technology for the following iphone/ipad app.
The app itself is a financial app, but we want more of a game look-and-feel of the app, so we probably don't want to use the builtin looks of the cocoa widgets. The elements on the screen will probably be some kind of blob-shaped images.
The app will essentially have five "blob"-shaped areas, spread out evenly across the screen. One of the blobs will be centered and larger than the other ones. Within each blob there will be clickable areas which will pop up "details" and menu-action blobs. These blobs are also graphics objects and must not take over the whole screen. The blobs should animate nicely when popping up. The graphics elements will have a couple of lines of text, which are generated, so the overlaying text itself cannot be part of the static background-image.
The main user interaction will be swiping within the center blob, displaying summaries of the items that are conceptually contained within the blobs underlying data store. Now and then, the user will drag and drop the item to one of the other blobs. While dragging, the item should be traced by a line and when dropping on the other blob, the item should be animated to look like it's being "sucked into" the blob.
Now, what kind of technique would you suggest for this app? Is Cocoa suitable in this scenario? Should I use a game framework like Cocos2D? All kinds of suggestions including example code snippets are most welcome.
I realize that this question might not be as straightforward and to the point as questions generally are on SO, but I hope your answers will come to use by more people than me. Thanks!
EDIT (MY SOLUTION):
I eventually ended up doing everything in UIKit, which was a lot easier than I expected.
Briefly described I used UIButtons with Custom style and an image background, which gave me full control over the visual appearance of the "items". I also found it very useful to manipulate the underlying CALayer of many of my other UIViews. It is often easier than drawing things from scratch using Core Graphics programming.
Another thing that was useful were the UIGestureRecognizer:s. I found them useful for both handling "real" gestures like swiping, longpress etc, but also for handling normal "tap" for UIView classes that aren't subclasses of UIControl. Two examples are UIImage, UILabel and UIView itself. That way I could handle taps for these simple classes. I could for example use a normal UIView, modify it's CALayer to change the look of it completely and still handle taps. Using this technique, I didn't have to subclass any views at all in my app.
The animations were pretty easy too, even though I had to use a non-public method to use "suck" animation, so my app will never pass App Store moderation. It was just a prototype anyway so I don't care.
When this app will be for real, I will probably implement it in HTML5/JavaScript wrapped by Phonegap. The reason for this is mainly reuse of existing mobile web services and also for code reuse across platforms. It will probably also be easier to hook into the existing security solution when using a webapp.
Cocos2d is great if you need to move elements around really fast as it is a layer on top of OpenGLES. I think from what you have said the UIKit will be fine, you get nice animation support, you can do some nice things with UIScrollViews to handle moving elements around etc.
If you need more detailed graphics support and lots of moving elements, particle effects etc then by all means go for Cocos2D but be aware that in Cocos2d the application works more on a scheduled update method, i.e. you get notified every 1/60th of a second to move stuff draw stuff etc, whereas with normal UIKit approach it is more event drive, i.e. I click a button and show a view etc.
Related
I am creating an application in Swift, and I would like to make an introduction screen that shows off my logo. I want the logo to slam down on the screen, which will then cause a crack, and then that crack slowly grows. I think I can figure out slamming the logo down (by shrinking a UIView of my logo to a certain point), but I am having trouble deciding how to create the crack that will form from slapping down. Do I use views? I am lost.
This is the closest thing that I found to what I would like to do. Sadly, I do not have this software.
https://www.youtube.com/watch?v=bh2y0Xs4IWA
I have created a similar effect before. And to achieve the crack a created multiple images of a growing crack and created an array of images for that screen crack. All you have to do then is animate the images if the imageView.
The other way you can Handel this is to actually draw the crack your self by code which is not difficult really, because in reality it’s just lines and then animate them. But in my experience just using the first method gives a much nicer effect because the images you use can have tons of effects using PS or equivalent.
I would suggest to go with third party like lottie. In lottie files there some animation you except there, you can also message the designer to help out animation. Its very simple to use in swift.
https://www.lottiefiles.com/
you can also check out my profile:
https://www.lottiefiles.com/parameshvadivel
Lottie animation are done in aftereffects using bodymoving extension and exported as json file to use in xcode.
I'm building an iOS application that will be drawing diagrams for the user to see and manipulate (move, add, remove elements) and I'm having trouble choosing how to implement the actual rendering.
I find the default cocoa-touch controls to be too limited for this purpose yet graphics frameworks such as Quartz/OpenGL ES/Cocos2D seem a bit overkill.
Can anyone suggest an approach to this situation or perhaps a library better suited to my needs?
Thank you.
You can have each drawn object (box, association) be a custom UIView subclass added as a separate subview of your main view. Each subview can catch events from finger touches.
Apple's Touches sample code shows how to receive events on subviews and move them in response to dragging motions.
I am in process of creating a multiplayer game similar to the Scrabble / Wordfued / Rummi. I am trying to see what would be best way go about implementing the UI and their interactions.
I would be having a framework which would keep track of all the pieces on the board and the AI for knowing if it is a valid move.
I am trying to figure out what could be best solution to handle the UI part. The game board would be larger than would the current iPhone screen could support. So the board would have an effect of a scroll view. The same goes for the game tiles using which user can play. These are not fixed amount of tiles/cards and the same could be more in numbers which would also need another scroll view kind of effect.
There would be many more effect's were the user can move a complete set of tiles/cards from the board and place it in another location of the board. Or even a tile in between the set of tiles on the board.
So I am trying so see if I should go with two scroll view provided by iOS and handle all the detaching the tile/card from one scroll view and placing the same in GameBoard scroll view
Or
Should I go with something like cocos-2d which provides more advance game UI handling capabilities.
Please do let me know your thoughts and feedback on what could be the best choice for the same. Thanks in advance for all your help.
Words With Friends uses native UIKit views. It is quite simple and uses a transition to move between the two degrees of magnification (close up and not close up).
You can do everything quickly in UIKit with a UIScrollview. You can use drag events to move tiles around the screen, even changing their perspective/look during dragging. Using UIAnimation would allow you to do simple frame based animation for things like dropping a tile.
Cocos2d will be quicker if you already know a similar gaming library. However if you choose it you you'll miss out on using Interface Builder and a lot of conveniences in UIKit.
If you're starting from a base of zero with either approach, then only use Cocos2d if you want particle effects (like stars and sparkles, UIKit has nothing for this).
Otherwise I'd say try UIKit, it's easier and there are more resources on the web.
My iPhone development is stepping up a notch and I'm looking at the UI. We're thinking of having a few nice interface-y features - things like dragging and dropping images onto one another from a gallery list, or similar.
How far does the basic iPhone interface stretch? Do most people create their own interfaces and code, and if so what's the base there? CoreGraphics? OpenGL?
I don't want to reinvent the wheel, but neither do I want to take an overcomplicated option if someone's done the work already.
There are several tiers to Cocoa-based interfaces. Generally, I recommend working at the highest level of abstraction that meets your needs for presentation and performance.
The base UIKit elements that you can place using Interface Builder or code are designed to handle the most common cases within an application's interface. These provide some degree of customization, depending on their type, but what you see is generally all you get. On the iPhone, Apple even tries to maintain a certain look and feel for these stock elements by rejecting applications during review that use them in ways that contradict the Human Interface Guidelines.
The next level down are custom UIViews. These can be made to look like anything through the use of Quartz drawing within the -drawRect: method. You can do your own touch handling by overriding methods like –touchesBegan:withEvent: or by using the new UIGestureRecognizers. Given the level of customization you can do here, this is where most people stop when tweaking their interfaces.
You can go a little lower than this by working with Core Animation layers and animations. You don't gain a lot, performance-wise, by using CALayers instead of UIViews on the iPhone, but they can be useful if you want to craft visual items that use the same code on Mac and iPhone. Custom animations may be required if you want to do something more than animate a view between two states linearly. You can even do some limited 3-D work using Core Animation.
Finally, there is OpenGL ES for display of full 3-D scenes and for really high performance graphic display. This is about as close to the metal as you're going to get when dealing with the iPhone display system, and it shows in terms of the amount and complexity of code you have to write. For complex 3-D work, this is what you will need to use, but for 2-D and even rudimentary 3-D I recommend looking first to Core Animation because of the code it can save you. If performance is unacceptable, then should you go to OpenGL ES.
Now, just because you need to use one of these technologies to work with part of your interface does not mean that it can't coexist with the others. UIViews are backed by Core Animation layers, and even OpenGL ES renders into a CALayer which can be placed in a view. Again, use the highest level of abstraction that is appropriate for that part of your interface.
We are making an app whose primary purpose is to display data, but we want to do so in a rich way. Our design includes several custom controls.
For example, one control will be a wheel the user can spin to pick a time of day. You see an entire circle - a disk - that has time values going out like spokes from the center. It needs to spin around the center. So -- it's nothing like apple's picker. It needs to animate nicely.
What library/framework would you recommend to do this? Quartz? OpenGL? Is there a 3rd party framework that people use that makes this kind of thing simpler?
Core Animation (i.e. CALayers) should be your first choice for animating objects that play nicely with UIKit. It has very good performance.