I know there are lots and lots of tutorials and discussions out there on how to implement a bouncy collectionViewLayout using UIKitDynamics.
There is even a WWDC 13 Session video addressing the exact topic of replicating the "message bubbles" in the iOS7 Messages App.
I created my own "bouncy layout" following the session video and using this tutorial which also provides the details on implementing a tiling mechanism, which makes sure things are running smoothly even with thousands of cells.
However, the result still is very different from what we can see in the Messages App and my goal was to replicate the EXACT SAME BEHAVIOR as the messages app.
No matter how many different values i provide for the UIAttachmentBehavior properties (length, damping, frequency), I can't get the bouncing right.
The session video says that setting a value > 0 for length breaks things, because the cells would not return to their actual position. However, i could only reproduce the smooth and fast decelerating the Messages App shows by setting ~0.5 for length ?
When the collectionView reaches it's bounds ends there is a nice exaggerated bounce for the last few bubbles in the Messages App where my "tutorial implementation" just doesn't bounce at all.
There is a discussion in the developer forums : Apple Dev Forums Discussion
Some suggest using multiple UIAttachmentBehaviors per Cell, others say applying UIView - spring Animations can give you this desired effect. There is even the assumption that the Messages App does not use UIKitDynamics + UICollectionView at all. (i doubt that Apple is not using this obvious technique for that)
So my question: Has anyone successfully implemented an exact replication of the Message bubbles behavior ? What more can i do to get answers regarding this topic ?
Related
Maybe I'm just searching for the wrong term, but I've been able to find very little information on this subject, and I think it could be a problem for my app.
A while back, there was an article on the accuracy of the touch screens on iOS devices, and it seemed quite poor compared to other phones. Here is a link a posting about it:
http://forums.macrumors.com/showthread.php?t=1660713
Anyway, many of the commenters referred to "perspective compensation" as a cause for the inaccuracy. Basically, they are saying that iOS intentionally registers touches above the actual point of contact to compensate for the typical viewing angle of the user or for the angle of their finger or something like that. I have found that there is some credibility to that claim myself by doing as one of the commenters suggested and trying to use my iPhone upside down. I did find that it was difficult to touch things in some cases, and I have also noticed this problem in one of the apps I'm developing.
So, in case you want to skip all that rambling above, here is why it's a problem for me:
I am developing an app that is intended to be used by two people at the same time. The iPhone or iPad is placed on a surface between two people who are sitting across from one another, and they are instructed to quickly and accurately touch items on their respective halves of the screen competitively. What the article's comments made me suspect might happen, and what I have also found in practice is that the person using the phone upside down will have trouble touching buttons and dots on their first try. I've also tested slowly with a stylus and found that the touchable area of a button does indeed extend below a button, or above the button for the person using the phone upside down, hence the discrepancy and problem/disadvantage for that person.
So finally, if you want to skip that also, here is my question: Can "perspective compensation"(if that's what it's called) be disabled programmatically, and can it be done for specific views of an app? Have any of you noticed this and dealt with it in an app of yours?
While I have found that "perspective compensation" does seem to be occurring, I have not found any official documentation of it, and therefore have no idea how or if it can be disabled. When I search for "perspective compensation," the only results I find are links to the same article and comments.
I can't help but expect that this may have been asked before or is solvable with a simple checkbox, but perhaps for lack of the correct term to use, I have been unable to find any leads.
Thanks in advance for any of your solutions or suggestions!
This can't be done with the current SDK. All we have access to is the touch location, which is at a single point. Other search terms you might try are "digitizer" or "raw touch data", but there is definitely no check box or simple option.
To implement this, you will have to compensate for the touch location yourself. You'll need to play around with a compensating offset value for the upside-down buttons. Hit testing on views is probably the best place to do this, then your buttons can just respond to events as normal.
I am building a UITableView-based Unity plugin which will be embedded by game developers into their Unity app. I am using the standard approach with dequeueing reusable cells, and the UITableViewCells contain simple UILabels and a UIImageView. The image inside the UIImageView is loaded via an asynchronous request.
There are no usability issues at all when launching the plugin as a standalone Objective-C app (in particular, scrolling works well with no lag) but when inside Unity, there is a "sticky" scrolling issue which arises randomly, i.e. the view scrolls but without inertia. I have not been able to pinpoint the exact actions which cause this behavior, but it happens usually when I scroll very quickly in one direction, or in short movements back and forth. The bug disappears when I scroll the view past the top or bottom (trigger the "bounce" effect, I am guessing this causes some hard refresh).
There is a very similar issue described here. The fix they suggest is to put
#define USE_DISPLAY_LINK_IF_AVAILABLE 0
inside the Unity-generated AppController.mm file. Unfortunately, this fix is unfeasible for the game developer who will be integrating our plugin, since it turns off the fastest and most reliable timing solution, and would require a fallback to other timing systems which would cause the game itself to lag or miss a portion of touch and accelerometer events.
I will most likely override drawRect for the UITableViewCells to reduce rendering time and memory usage, and if that fails, write a version of the plugin in OpenGL. However, I was wondering if anyone had a similar issue and knows a quicker fix, either in Objective-C or inside Unity, that is non-destructive (like the timing fix described above). Thanks very much.
I had the same trouble that you have described. I've fixed it by commenting the line
//#define USE_DISPLAY_LINK_IF_AVAILABLE 0
I have this problem with performance of my iPad app..
For developing, I use MonoDevelop, which takes care of Garbage collecting. Still my questions are rather generic, I'd say.
OK, I use TabBarController with 5 NavigationControllers. Inside nav controllers there are some controllers, whose views are TableViews or ScrollViews. Next child is always just regular view.
I have a few questions:
1) TableViews never scroll smoothly. I have some alpha transparency, but since I did my graphics in Photoshop and not programmatically, this transparency should not cause much problems. It doesn't matter whether I have few or many results in table.
On the other hand, I have ScrollView which serves same purpose, i.e. to be a table with different layout and buttons have Photoshop generated transparency as well. It works perfectly.
For tables I applied DequeueReusableCell() which works fine (I see that memory usage is not increasing after scrolling). So why would tables scroll so jerky?
2) My app supports rotation. When I scroll table or scrollView and simultaneously tilt the device a bit, I get maybe 1 or 2 FPS. What is the best way to implement rotation? As I understand, ShouldAutorotateToInterfaceOrientation has to be overridden in all controllers in NavigationController chain. Also, I need to add observer in View I want some changes to happen. Do I have to use BeginGeneratingDeviceOrientationNotifications() in all views or is it enough to do it in Main.cs? Maybe this slows it down?
3) After some time app starts getting memory warnings and then crashes eventually. I tried to read logs and run app with Instruments, but can't find the cause of crash.
4) What exactly happens to a View popped from NavigationController stack? I can't reuse it. But could it be that Monotouch (or me) doesn't dispose it correctly?
I have almost same app for iPhone without support for rotation which never crashes. I think I'm doing something wrong with this rotation, but I'm not sure what.
Any help will be appreciated the most. So, thank you in advance.
Regards
1 - transparencies are always a problem. Even if you're not rendering the images in code, the phone still needs to do the compositing of the image, and that may take a lot of time. UITableViews have to calculate the final composite image every time a new cell is displayed, or the table is scrolled, while UIScrollViews can calculate only once, since the image won't change. So be very careful about it, turn the transparency off, and check if performance improves.
2 - You shouldn't need to notify every uiview in your application. Receive the notification in the controllers that you want to update only, like for example if you want to rearrange items in the UIViewControllers view.
3 - you have one (or many) memory leaks. My guess is that MonoTouch probably can't garbage collect UIViews or UIViewControllers, because they're still being linked from somewhere in UIKit, like a UINavigationController
4 - UIViews are not disposed by UIKit until the app gets a memory warning notification.
Like Eduardo said, alpha transparency in Views comes at a price. There are some tools that you can use to identify the bottlenecks discussed in these WWDC 2011 talks from:
https://developer.apple.com/videos/wwdc/2011/
iOS Performance and Power Optimization with Instruments
Understanding UIKit Rendering
In the "Debug" menu of the iOS simulator you can find various debugging tools that will color different regions of the screen indicating where some problematic rendering is taking place. The WWDC 2011 talks show what you can do to fix those problems.
For your memory problems, it is very likely that you have something pointing out to your objects around, so you need to make sure those objects are gone. While we currently are not shipping our new profiler for MonoTouch that can show the source of the problem, I wrote a "poor man's" debug utility that will help you narrow down which objects are alive. It is available here:
http://tirania.org/tmp/HttpDebug.cs
Call HttpDebug.Start () from your application and as you run, connect with a web browser to http://localhost:5000 to get a list of live Objective-C objects surfaced to C#. The tool is not perfect and shows a lot of irrelevant data, but it would at least give you an idea of what is going on.
I have been following a iOS tutorial on raywenderlich.com, called "How To Create a Simple Magazine App with Core Text" LINK
The App works great on the simulator, but when i build it for my iPad 1G, the scroll view is not fluent at all, the performance goes down, and the view becomes useless.
I have been trying to get help at the raywenderlich.com forum, but with no luck.
Is it a general problem with Core Text or what do you think?
Thansk
When trying to debug lag issues, try and find similar apps on the Store that are doing similar drawing. If your performance does not equal that level, then your code can obviously be improved.
For instance today, I was coding a UITableView, but when I ran it - it was not fluid in scrolling. I just knew that something wasn't right as the hardware could obviously handle it; looking at scrolling performance in the Music app for instance. So I used the profiler tools and eventually tracked down my error.
When using the Ti.UI.iPad.SplitWindow what is the best(cleanest looking) way to update the detailView?
The options I can think of are changing the positions of elements in the detailView event or to show()/hide() vs open()/close() on an orientationchange event. I know that using the native UI components on the iPad should dynamically update to the layout width/height of the iPad but in my case the content on each detailView will have it's child objects positions updated on orientationchange. I'm just trying to get the smoothest from your all experiences. Even if I have to build custom animations I just want to start this correct from the beginning so no current code exists yet. Thus none included.
I'm hoping this isn't a duplicate as I searched before I ask but there are no Titanium based questions on this topic I can find. Possible but still different to what I'm asking.
The smoothest experience will be delivered by changing the least. I don't know what animations you are envisioning, but I would nudge you towards keeping it simple.
Here's a quick example of an orientation change in an iPad app I built recently. I had a bunch of images in a view with layout: 'horizontal'. Due to a nice bug, the images wrapped automatically. When the user reoriented the device, I animated the width of the view, and the images automatically and animatedly resorted themselves.
I've also had some clients at a large corporation get their hearts set on really complicated changes to the layout whenever the user reoriented the device. This resulted in a really unsatisfactory app that took 10-20 seconds to reorient. We made a lot of optimizations, and a lot of improvements in both their code and the underlying framework, but the heart of the problem was the complex design.
Take the time to consider if you really need complicated changes every time the user reorients, and how much benefit you are offering to your users. Also consider the cost to the user (not just to the device) of presenting them with a new UI.
Past that, you're probably not going to get too many answers until you put some experimentation in to this. If you come back with some code and some questions to go along with it, I can reformulate my answer to better pinpoint your situation.
Hope this helps! -Dawson