I am currently programming a writing / drawing app and use Metal to render the lines and so on.
I now want to support multiple pages. Similar to GoodNotes or other Apps I want to swipe left / right to go to the next page. I now have two options.
Use just one View with CAMetalLayer that renders all pages next to each other and just use and offset to "show" the next page or
Use multiple Views with CAMetalLayers and use something like a UIPageViewController to swipe between the different views.
My Question is, is Metal designed for using multiple MetalViews? Or since I would probably only show two pages at the time would it be more efficient to use only one Metal View? Also I am not sure how good the UIPageViewController would handle multiple Metal Views and how the gestures of my Drawing App would interfere with the gestures of the UIPageViewController.
I know this is a general maybe even opinion based question but I have not so much experience with Metal and I could use some input on how to solve this problem.
Thank you very much in advance!
Related
I'm wondering what the best way is to do a split NSToolbarItem like Xcode does. I've read the documentation, but can't figure out a way to do this. Any ideas?
It's a custom control. Basically it's a custom NSView, drawing a background the same as a button/popup, draws the "selection" on both sides, handles mouse events and displays one of two menus based on which side was clicked. It's not difficult, but it's not a trivial amount of code to whip up and share either. Just look at any examples of making any kind of clickable custom view and you'll be on your way.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/SubclassingNSView.html
Do someone has an Idea, how to implement a Layout in RCP,
where the Views would look like Tabs and appear nested?
The Tabs should have all the advantages of Views - can be dragged to the desktop to become a detached view, be tiled near each other, rearranged etc.
On the picture the views: View4 and View5 are nested into View1.
In my experience, something like this will not be easy - there's likely going to be a lot of custom coding in your future. I'll try to cover this more from a high level architecture standpoint, since there'll be a lot of details you'll need to figure out specific to your requirements and strengths.
There's two ways you can go about this I think:
1. write a view extension where the contents of that view are other views.
This would be less work up front, but might be harder to get view rearrangement to work. Based on your mockup, this means View1 is an instance of this view, and is responsible for rendering the tab controls for View4/View5, and telling those views to render their content. You can probably look at MultiPageEditorPart for some inspiration, though you'll probably want to render the tabs a bit nicer.
In this case, your subviews will likely plug in specifically to their parent view. Drag and drop support within the view wouldn't be too bad, though pulling them out of the view would involve a bit of work. This article provides a basic intro to drag-and-drop; google can provide the rest.
2. write a custom presentation to render your views in this way.
This one might be a bit more work up front to learn about how the presentation layer works, but once that is done, it will probably be easier to get all the features you're looking for. See this article for an introduction to presentation layers.
In this case, all your views will be treated by the plugin system as top level views - your presentation layer decides where to render the areas for the view contents. I've used presentation layer for something similar to this, but in my case, the views were all statically positioned. That said, since everything is a regular view, you should be able to re-use the existing drag-and-drop functionality to rearrange views with a lot less effort than the other option.
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.
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.
This might be trivial for some of you, but I have two screenshots from the Lose It! app in which I'm curious how two different screens were put together.
The first:
That middle graph which shows the statistics chart. Is that a custom image being drawn on top of with Core Graphics / Quartz to achieve the desired numbers? Is the yellow line that's being dynamically allocated all the work of Quartz?
And second:
This one might be a bit easier, but the whole bar which looks like a native UIKit widget, which contains [Budget, Food, Exercise, Net, Under]. There appears to be a drop shadow above it. Are they doing a drop shadow on the UINavigationBar? Is the menu below it just a UIImage that a designer was able to craft to look like the UINavigationBar?
If there's a blog out there which teaches UI tricks such as these, I'd love to read more.
1) Yes, it's likely a view that uses the chart as a background and then uses core graphics to render the line,
2) This could be a single view divided into four sections. Each section has two lines of text drawn with different colors. It's possible that each section may be a view that encapsulates this behavior.
I'm not aware of any blog that teaches these "tricks". It's really a case of understanding what functionality is available and then using it creatively to develop your UI.
For example we know it's possible to;
Draw images at different sizes/positions.
Draw text in different fonts, sizes, colors, alignment
Draw primitives
Really, when you have those you can create pretty much anything.
I think there's an SDK sample that demonstrates using custom views to create a fancy timezone style applications. That might be one worth checking out.
Update: found it, it's here.