We know the static vs. singleton debate, so this question isn't about legitimacy of the static keyword.
When you have a static class, how is the memory for that handled by Monotouch. Are its members removed when a memory warning is received? Are there any guidelines regarding use of static classes in Monotouch?
Static classes and members will hang around the lifetime of your application.
Generally I wouldn't worry about static classes. The largest thing to worry about is making sure you are properly cleaning things up in ViewDidUnload in all your controllers.
Here you should:
Dispose and set any outlets to null (ReleaseDesignerOutlets will do this in later versions of MonoTouch) you have to do it yourself for any views created from code
Do the same for any instances of UIImage, UIFont, etc. that are created in ViewDidLoad
ViewDidUnload should be a mirror image of ViewDidLoad
ViewDidUnload is called on low memory conditions for controllers that are not currently on screen, such as ones down the stack in UINavigationControllers, etc.
In addition, you might want to hook into the low memory notification from UINotificationCenter on any helper classes that cache UIImage, UIFont, etc.
Freeing up views and images will free up much more memory that you would get by how much memory static classes are using.
Related
Does Mapkit on IOS support dequeuing of overlays? (like it does annotations). If so what is the code for achieving this?
Background: With annotations I believe you can add many, leaving MapKit to instantiate views when required for them via the dequeuing approach. What about the same thing for overlays however if I have many across the country? Do I need to write the code for checking which overlays I have are visible or not and then instantiate them / remove them myself in realtime?
Map Kit does not support reuse of overlays in the same way it supports doing this for annotation views. One of the reasons for this must certainly be that the two objects are not analogous. Overlays are model objects that represent an area on the map, whereas annotation views are view objects used from time to time to display the location of an annotation on the map. The technique of reusing view objects (as opposed to creating individual ones for every use) is an optimization that is used in a couple of other places in UIKit, notably for Table View Cells and various bits of Collection Views.
The view reuse pattern is to establish some data index (table index paths, map coordinates) and then have a delegate provide an appropriate view object to use when a particular index/location comes into view. When the data object passes out of sight, the view object is recycled in a queue.
An annotation is analogous to an overlay, and MapKit does not provide reuse for them either and for good reason: they are the data that is being displayed!
The analogous object to the annotation view is an overlay renderer, which (of course!) provides rendering for an overlay. I assume that the reason these are not reused is because they are not view system objects and presumably much more lightweight, so there is little benefit from reuse. We find evidence for this in the fact that until iOS 7.0 the MapView delegate did provide a view object for overlays and this was replaced by the renderer concept.
I hope that helps.
What problem is this causing for you?
I want to understand some best practices regarding using MVVM and multithreading. Let us assume I have a ViewModel and it has an observableCollection. Also, let us assume I pass this collection to another service class which does some calculation and then udpates my collection.
After a point I realize that I want to make this a multithreaded call. When I make the call to the service class using threads or tasks what results is a cross thread operation. The reason is quite obvious because the service class updates the collection whcih in turn will update the UI on the background thread.
In such scenarios what is the best practice? Should we always write our service class in such a way that it first clones the input and then updates that cloned copy? Or should the view model always assuem that the service calls might be multithreaded and send a cloned copy?
What would be the recommended way to solve this?
Thanks
Jithu
A solution that might solve the cross-thread exception is by implementing the OnPropertyChanged in the base class of all ViewModels to switch to the correct thread/synchronization context so all properties in the View that are bound to the changing property will have their handlers called on the correct thread. See: Avoid calling BeginInvoke() from ViewModel objects in multi-threaded c# MVVM application
If/when you create copies you are postponing the synchronization and, in many cases, making it harder than need be.
A web service will always return new objects, how you, or a framework, updates the model using these object is up to you. A lot would depend on the amount of checks and updates coming in. There is no recommended way, see whatever fits the applications requirements.
After reading this SO question, I noticed that the link in the question made a reference to Microsoft.Xrm.Client.CodeGeneration.CodeCustomization,Microsoft.Xrm.Client.CodeGeneration.
What advantages it has over the standard code gen? According to LameCoder it changes all the entities to inherit from Microsoft.Xrm.Client.CrmEntity rather than `Microsoft.Xrm.Sdk.Entity. What changes does that make and what other changes are created?
Here is the best site I could currently find on what it does:
CrmSvcUtil & OrganizationServiceContext enhancements such as lazy loading
Simplified Connection Management with Connection Dialog UI
Client Side caching extensions
Utility Extension functions for common tasks to speed up client development
Organization Service Message utility functions to make it easy to call common messages such as BulkDelete, Add Member to Team etc.
Objects to support the Microsoft.Xrm.Portal extensions
The only real downside I can see to inheriting from CrmEntity is that it requires the Microsoft.Xrm.Client dll to either be Gac'd on the server, or IL Mergered into the Entities dll.
Besides that one downside, here are the features I see it adding:
Moves INotifyPropertyChanging and INotifyPropertyChanged into the base class, making resulting code smaller
Defines additional class Attributes
System.Data.Services.Common.DataServiceKeyAttribute
System.Data.Services.IgnorePropertiesAttribute (I'm assuming this one sends less data over the wire?)
Microsoft.Xrm.Client.Metadata.EntityAttribute (I believe this is used to support LazyLoading
Option Sets properties are changed to nullable ints
Money properties are now nullable decimals
Setting a property value to the value it already is, will not trigger a property changing/changed event
SetPrimaryIdAttributeValue results in smaller code.
I'm using Castle Windsor and DynamicProxy to implement persistence Lazy Loading from scratch (I know NHibernate could be an option etc.) I have implemented a custom component activator to always instantiate my business classes as proxies.
I had my doubts concerning the component activator lifestyle (What is the expected LifeStyle of a Castle Windsor component activator?). Krzysztof Kozmic kindly answered that "Every component in Windsor will get its own activator instance".
Faced with a big memory leak in my application I have come to find that an explicit destructor in this class is never called (in my case at least). Is Castle freeing the activators appropriately, namely, when the typed factory is disposed?
Classes
.FromAssemblyContaining(typeof(QuantityType))
.InNamespace(typeof(QuantityType).Namespace)
.WithService.DefaultInterfaces()
.Configure(reg => { reg.Activator<ColMsProxyComponentActivator>(); })
.LifestyleTransient() // We really want new entities every time a new one is requested
As a side note, would it not be useful to have the ability to explicitly declare the component activator lifestyle? In my case, there's no reason why it can't be a Singleton, and that would save some memory and processing.
The most common reason for perception of memory leak in castle Windsor is the misunderstanding of how to deal with any component that doesn't have a system definable lifetime, most notably, transient components.
The designers of castle decided that the responsibility for both creation and destruction are the container's concerns. That being the case, the default behavior is to track all objects the container creates. That means, if you don't release them, you're going to see what looks like a memory leak.
If you read this and are thinking "I know, I know, I'm releasing all my stuff", you might want to prove to yourself you are by changing the default release policy to "don't track". If your memory leak goes away you probably aren't releasing something somewhere.
I think this is the code for changing the release policy:
container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();
If you're thinking, I'll just leave that NoTrackingReleasePolicy on because it solves my issue, here's a note from the authors in the code:
[Obsolete("This class is a hack, will be removed in the future release and should be avoided. Please implement proper lifecycle management instead.")]
Here's a useful link about releasing objects if you're unaware how it all works
Hope this helps
I'm not sure how to maintain a bi-directional relationship between my core data entities and some objects that are instantiated when the entities are created and committed to the database.
I have many subclassed MKAnnotation objects with one-to-one relationships to the entities. Every time my fetchedResultsController executes a new fetch, I am assuming that the results from a previous fetch are released and the NSManagedObjects that are fetched are remapped in memory. So my one-to-one relationships are broken. If I can save a pointer to the MKAnnotation objects in core data, that would fix half of the problem (the relationship in one direction). Does this make sense? How would you do this?
I delete all of the core data content when the application is restarted, so long term persistence of the relationship information is not a concern that I have.
Mixing pointers and managed objects is usually futile because Core Data has so many optimizations in place that direct memory management is all but impossible e.g. an object may revert to a fault.
You're really going about this the wrong way. Core Data isn't primarily a persistence API, its a data modeling API intended to provide the complete model layer of a Mode-View-Controller design app. As such, you can use it without saving anything at all. If you are using Core Data and you have data such as map annotation, the annotation should be modeled in Core Data. Doing so will simplify everything.
Since there is no MSAnnotation class but merely a MKAnnotation protocol, the simplest solution in this case would be to create a NSManagedObject class that implements the MKAnnotation protocol. You can either convert location data like CLLocationCoordinate2D into NSValues or better yet, just make attributes for them. Since the class implements the protocol, you could pass the managed objects anywhere you would pass any protocol object.