Activity for karatasi - flip cards on iPhone
-
Christa Runge committed [r4018]
Cleanup height of table cells
-
UITableViewAutomaticDimension: table view chooses appropriate height based on your cell's content. UITableView.rowHeight: is ignored as soon as the delegate implements the tableView:heightForRowAtIndexPath: method. The former is more efficient if all cells have same height.
-
Use UIBarAppearance to retrieve the dimensions of Toolbar and NaviBar.
-
Semantic data types
-
Cleanup header files - move private properties to implementation
-
Reduced prio. We are not yet ready for this. Migrating to the persistence API will need major refactorings as preparations. Still we need to re-activate our own persistence implementation
-
Migrate to persistence API
-
Reduced prio. We are not yet ready for this. Migrating to the persistence API will need major refactorings as preparations.
-
Minimum height of table row in card list
-
Bugfix: presentWithNavi shall also support to present view controllers that don’t support state restoration.
-
Derive all view controllers on navigation stack from BasePresenting view controllers.
-
Cleanup: remove unused property and method (initWithToolbar, showsToolbar).
-
Cleanup: switching for OUR_PERSISTENCE
-
In landscape mode show Help view controller.
-
Improve method name
-
New #define to switch between the UI restoration and our own legacy persistence system
-
Autorotate is broken - detected at svn 4009
-
Autorotate is broken - detected at svn 4009
-
Fixed in svn 4010
-
Fixed #641 (Autorotate is broken)
-
karatasiAppDelegate.isStartupFinished is still set to NO
-
Autorotate is broken - detected at svn 4009
-
Add logging for view controllers - in the hope that it helps to track down the root cause of an error message related to an unbalanced animation.
-
Configure an application-specific name for the WKWebView user agent.
-
Use UIBarAppearance to retrieve the dimensions of Toolbar and NaviBar.
-
Not required. A very well working alternate solution is to enclose every modal view controller in its own UINavigation controller.
-
Cleanup, remove deactivated code.
-
Startup view controller need not support UI state restoration.
-
Show startup view controller also on top of modal view.
-
Present startup view controller modally. This works fine over the DBListView controller, but is in conflict with modal views.
-
Cleanup: Remove RotViewController
-
Preservation and Restoration (ongoing): Use DBListViewController as root.
-
Preservation and Restoration (ongoing): Cleanup About view controller, remove remnants of our proprietary UI state restoration.
-
Preservation and Restoration (ongoing): Modal views are restored.
-
Preservation and Restoration (ongoing): DBListViewController is restored.
-
Preservation and Restoration (ongoing): Create the dblist view controller early.
-
Hide and show the toolbar according to the wishes of the topmost view controller.
-
Cleanup - reduce root view controller
-
Use RootViewController as root view controller.
-
Don’t call closeDown if the controller does not support it.
-
Clean-up: add RootController again to the project.
-
Clean-up: move RootController to controllers. Remove it (temp) from the project.
-
Revert to svn3989. The reduction was premature; it crashed on application termination, and the dbListViewController had no toolbar.
-
Reduce RootViewController to the minimum.
-
Add new class RootViewController. We want to present the StartupViewController as modal view.
-
Preservation and Restoration (ongoing): Add didDecodeRestorableStateWithCoder method to the app delegate. This methods is planned to be used to present the startup view.
-
Preservation and Restoration (ongoing): Simplify creation of the DB navigation controller. Ensure that StartupViewController is unique.
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) UIKit collects the references to all involved objects. If not before, they are brought now to life (created or loaded from a nib file). b) all involved objects are triggered for restoration. At this time it is guaranteed that...
-
Preservation and Restoration (ongoing): prepare all view controller classes to participate. Add required methods and mechanisms.
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) UIKit collects the references to all involved objects. If not before, they are brought now to life (created or loaded from a nib file). b) all involved objects are triggered for restoration. At this time it is guaranteed that...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism. To opt in, the application delegate must implement both methods (application:shouldSaveApplicationState:) and (application:shouldRestoreApplicationState:),...
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) UIKit collects the references to all involved objects. If not before, they are brought now to life (created or loaded from a nib file). b) all involved objects are triggered for restoration. At this time it is guaranteed that...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) UIKit collects the references to all involved objects. If not before, they are brought now to life (created or loaded from a nib file). b) all involved objects are triggered for restoration. At this time it is guaranteed that...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldSaveApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) UIKit collects the references to all involved objects. If not before, they are brought now to life (created or loaded from a nib file). b) all involved objects are triggered for restoration. At this time it is guaranteed that...
-
Restoration: State restoration is performed during application startup, even before the user interface is visible. The captured object graph is not a simple tree, but usually contains plenty of cyclic pathes. For this reason the state restoration is performed in two phases: a) all involved objects are brought to life (created or loaded from a nib file). UIKit collects their references in this phase. b) all involved objects are triggered for restoration. At this time it is guaranteed that all involved...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
Preservation and Restoration (ongoing): refactoring: initialisation method for DBNavigationController (initWithRoot).
-
My current understanding of the preservation/restoration API: Preservation: 1) iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. 2) the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: - iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. - the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: - iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. - the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
My current understanding of the preservation/restoration API: Preservation: - iOS captures the "vital state" of an application during its termination. The resulting "object graph" has captured all "vital objects" with their state and their relationships. The idea is to have the vital state as small as possible. - the application must opt-in to this mechanism (application:shouldRestoreApplicationState:). Note: The opt-in pattern helps to maintain backwards-compatibility of iOS versions, and prevents...
-
A few remarks: 1) With our legacy handmade preservation/ restoration solution, each view controller on the navigation stack has the responsibility to remember its siblings above itself on the stack, and to pull them in during the restoration phase. Note: this is the semantics of a containment (drill down into details), and from perspective of the model this seems not so wrong. However, this solution results in a weird coupling of the controllers. A much better design is to give the navigation controller...
-
Preservation and Restoration (ongoing): StartupViewController must participate in state restoration because it is the root controller of the DB navigation controller.
-
Preservation and Restoration (ongoing): Move creation of the enclosing navigation controller for modal views to the App delegate.
-
Preservation and Restoration (ongoing): Bugfixes, and still a lot of debugging code.
-
Preservation and Restoration (ongoing): AboutViewController and its enclosing navigation controller are created but not yet wired correctly.
-
Preservation and Restoration (ongoing): DBNavigationController supports state restoration.
-
Document purpose of the @class forward declarations.
-
Preservation and Restoration (ongoing): playing with the API
-
Preservation and Restoration (ongoing): playing with the API
-
Preservation and Restoration (ongoing): prepare preservation callbacks for the modal controllers.
-
Preservation and Restoration (ongoing): prepare preservation callbacks for the non-modal controllers.
-
Integrate the preservation and restoration API (ongoing): app reset button integrated and tested.
-
Prepare integration of the iOS application and restoration API: opt in, add restorationIdentifiers to the view controllers.
-
Cleanup: remove obsolete methods.
-
Cleanup: remove commented lines and obsolete methods.
-
Cleanup: remove commented lines and obsolete methods.
-
https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoringState.html#//apple_ref/doc/uid/TP40007457-CH28-SW1
-
Persistence for tableviews
-
Migrate to persistence API
-
Rotation of About view has wrong constraints
-
Resolved in svn3969. For details on solution see also #634.
-
Position of headline during Test / Drill should be a tick lower
-
Resolved in svn3969. The solution follows the suggestion at stackoverflow: every modal view that needs a navigation bar is enclosed in an intermediate navigation controller.
-
Cleanup: remove remaining references to handling of navigation bar in BaseModalViewController.
-
Toolbar should get different color than the table views
-
Cleanup: remove references to ControllerExtension where not needed.
-
closeDown chain ignores the intermediate navigation controller.
-
Cleanup: remove all remains of navigation bar handling from the modal views.
-
Release the relationship between presenting and presented view controller at the end of a modal view.