In iOS SDK, NSDictionary has got writeToFile and dictionaryWithContentsOfFile methods to write a dictionary into a file and to read the contents of a file as dictionary. Is it possible to do the same in WP7 (C#) ?
Yes, but you have to serialize the dictionaary and write to a file yourself.
Alternatively you could add to IsoaltedStorageSettings and let the framework do the serialization for you.
I believe the SilverlightSerializer library is capable of serializing a dictionary; you could serialize your dictionary to a byte array and write it to Isolated Storage.
SilverlightSerializer examples: http://whydoidoit.com/silverlight-serializer/
Or try SharpSerializer, there's a WP7 version available (and a NuGet package): http://www.sharpserializer.com/en/tutorial/index.html
#saikamesh, Here is a thread that covers XML serialization of dictionary in .NET. Why isn't there an XML-serializable dictionary in .NET?. It lists a number of different approaches. You can then write the output string to a file in isolated storage.
You can find mappings of iPhone classes to Windows Phone classes at iPhone and Android to WP7 mapping site
Isolated storage provides a file system. Serialisation is an orthogonal problem.
It is possible to write any object graph into IsolatedStorageSettings provided every object in the graph is DataContract serialisable. Many common framework types are not, for example GeoCoordinate.
Arguably, IsolatedStorageSettings is a dictionary. But the caveat stands regarding DataContract seralisability.
It is equally possible and a lot smarter to write your dictionary to a file, because the more you store in ISS the longer it takes to instantiate. This can seriously affect app load and resume times. You will still have to manage serialisation yourself to the extent that unsupported classes are involved. Your biggest handicap would be the absence of BinaryFormatter from the framework (I don't know whether Mango adds it.)
Related
I've been using Ruby Selenium-Webdriver for one of the automation scripts I'm developing and I'm being asked to use Page Objects, we use page objects a lot however for this application I am using CSV file instead, I have defined all the xpaths that I'm using in my application in a CSV file and I'm parsing that CSV file in my script to refer to those objects, I would like to know is there much of a difference in using a class for defining Page Objects or using a CSV file instead apart from performance concern? I believe using a CSV file will be an addon for us from configuration standpoint and will make it much easier to maintain, any suggestions on this?
Edit - In our use case, we're actually automating applications built on a cloud based tool, so basically all the applications share same design structure from HTML standpoint so we define xpath patterns in CSV and then we pass certain parameters to some custom methods that we've developed to generate xpath's automatically using the CSV instead of finding those manually as its overhead for us because we already know that all the applications will share similar xpath pattern for all elements.
Thanks
I think, POM is better than CSV approach. In POM, you put elements for a page in a separate class file. So, if any change is to make then it's easier to find where to change/maintain. Moreover, it won't get too messy as CSV file and you don't need to use extra utility function to parse those.
There is also a pageobjects gem that provides a set of libraries over and above webdriver/watir, simplifying the code.
Plus, why xpaths? Its one of the last recommended ways to identify an element.
As for the frameork aspect, csv should be more of a maintenance problem than PageObjects. Its the basic difference between text and code. You enforce Object oriented approach on your elements in PageObjects but that is not possible with csv.
In the best case scenario, you have created a column/separate sheets defining which page that element xpath belongs to. That sounds like an overhead. As your application / suite grows there can be thousands of elements. Imagine parsing/ manually updating a csv with that kind of data.
Instead in PageObjects, your elements will be restricted to the Page. Any changes to the app will also specify which elements may get impacted. Now, when define your element as an object in PageObject, rather than css, you also dont need to explicitly create your elements by reading the csv.
It completely depends on the application and the type of test you might perform.
Since it is an automated test script, you do not have to really worry about the performance of the script (it might take few more milli seconds to parse, which should be OK).
Maintaining all the elements identification properties & corresponding actions in a CSV file will make the maintenance easier and make the framework application independent which are nice. But maintaining your framework is bit difficult to make it more robust. Both approaches have its own pros and cons.
Refer to below posts [examples are in java - but you will get the idea]:
Keyword driven framework
Advanced Page Objects
Update:
If you like both, you can comeup with your implementation to easily integrate these too.
#ObjectRepository(src="/login.csv")
public class LoginPage{
private Map<String, WebElement> elements;
public void login(){
elements.get("username").sendKeys('');
elements.get("password").sendKeys('');
elements.get("signin").click();
}
}
Ie, define all the elements in a config file like csv/json etc. Let the page object refer to the class for the page elements. All the methods will be part of the page class.
I used the isolated storage before to save text files, xml files and images. However, is it possible to save variables of type IEnumerable using IsolatedStorage or any other resource in windows phone 7??
Thanks,
You are misunderstanding core concepts.. There is no such thing as "saving variables", you save objects. Your variable points to an object, and that objects implements IEnumerable. Is On WP7, it is the object's actual class that determines whether that object can be serialized and stored on the ISO directly. If that actual collection class does not support serialization, you will have to re-wrap all its current elements into a List/Array/Dictionary/Stack/Queue - literally whatever what supports being serialized - and store that instead of.
Once you have an serializable collection, then your code for saving gets reduced to something as trivial as:
IsolatedStorageSettings.ApplicationSettings["blah"] = your_serializable_collection;
IsolatedStorageSettings.ApplicationSettings.Save();
and in general, that's it. Retrieving is similar:
var items = (SomeCollection)IsolatedStorageSettings.ApplicationSettings["blah"];
where SomeCollection may be an IEnumerable, a List/Array/Dictionary/Stack/Queue - whatever you had put there and whatever is implemented by the actual collection class.
If you want, you may use IsolatedStorageFile and write files directly, but unless you have a good reason to - there's no point in it, as using the common dictionary is far simplier.
In my other post you'll find some links:
How to do isolated storage in Wp7?
Use for saving/loading of data List which are serializable out of the box. Last time i tried deserialize an IEnumerable I got errors...
Can anyone explain differences in practise between NSArrayContoller modes (Class / Entity}?
I am just facing some debugging issues in my document based Core Data desktop application (using Entity mode for all my controllers).
My database structure became quite complicated and it takes so much time to find wrong bindings (mistyped key-paths, etc..). I have also generated classes for each entity in my data model.
Would it make any difference in tracking binding mistakes if I switched all my controllers to the Class mode?
Entity is for array controllers whose arrays contain Core Data managed objects.
Class is for array controllers whose arrays contain plain (not managed) objects.
So, no, switching an array controller that holds managed objects over to the unmanaged-object mode will not help.
My database structure became quite complicated and it takes so much time to find wrong bindings (mistyped key-paths, etc..).
You should get an exception about that in the Debugger Console.
I'm trying to find out what my choices are when I'm going to use user (persistent) settings.
In vs Studio this is possible in the properties of your project but I'm getting to know the limits there:
Only values are allowed that can be converted to string.
Collections (e.g items in a Listbox, with a name and value) cannot be saved.
What I would like to know, how do you implement user settings with collections, and how do you make user settings?
Emerion
If I understand correctly I think you're probably looking for serialization, and since you mention values that can't be converted to string I assume that you'd probably want binary serialization.
The System.Runtime.Serialization namespace contains classes to help you with this and here's an article that might be useful: Serialization in the .NET Framework
I'm trying to figure out how to decide when to use NSDictionary or NSCoder/NSCoding?
It seems that for general property lists and such that NSDictionary is the easy way to go that generates XML files that are easily editable outside of the application.
When dealing with custom classes that holds data or possibly other custom classes nested inside, it seems like NSCoder/NSCoding would be the better route since it will step through all the contained object classes and encode them as well when an archive command is used.
NSDictionary seems like it would take more work to get all the properties or data characteristics to a single level to be able to save it, where as NSCoder/NSCoding would automatically encode nested custom classes that implement the NSCoding interface.
Outside of it being binary data and not editable outside of your application is there a real reason to use one over the other? And along those lines is there an indicator of which way you should lean between the two? Am I missing something obvious?
Apple's documentation on object graphs has this to say:
Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.
…
Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.
The way I interpret this is that, if you want to store simple values, serialization (using an NSDictionary, for example) is a fine way to go. If you want to store an object graph of arbitrary types, with uniqueness and mutability preserved, using archives (with NSCoder, for example) is your best bet.
You may also want to read Apple's Archives and Serializations Programming Guide for Cocoa, of which the aforelinked page on object graphs is a part, as it covers this topic well.
I am NOT a big fan of using NSCoding/NSCoder/NSArchiver (we need to pick a name!) to serialise an object graph to a file.
Archives created in this way are incredibly fragile. If you save an object of class Foo then by golly you need to make sure when you load the data back in you have a class Foo in your application.
This makes NSCoder based serialisation difficult from the perspective of sharing files with other applications or even forwards compatibility with your future application.
I forgot to list what I would recommend.
NSCoding can be ok in certain situations: if you're just doing something quick and simple (although you do have to write a lot of code - two methods per class to be serialised). It can also be ok if you're not worried about compatibility with other applications.
Export/import via property lists (perhaps using the NSPropertyListSerializaion class) is a fine solution. XML based plists are easy to create and edit. Main advantage to plists is that you're not tying the file format to just your application.
You can also create your own XML based file format and read/write to it using NSXMLDocument API and friends. This really isn't much more work than using property lists.
I think you're a bit confused, NSDictionary is a data structure, it also happens to implement the NSCoding protocol. So in essence, you could either put all your data into a NSDictionary and have that encode itself later on, or you can implement the NSCoding protocol and encode your object tree using the NSCoder API. Based on the type of NSCoder object passed in to the encodeWithCoder: method, is the output of your encoding.