I currently have a project which utilizes an SQLite database containing objects. Each object has attribute information as well as coordinate information.
Currently my method of displaying these points is to build graphicslayers from lists extracted from the sqlite database. This all works fine but i'd like to query the graphics based on their attributes and toggle each accordingly.
Is this methodology the only solution to work with local data? Are there any solutions that could involved creating a featurelayer from the data in the sqlite database?
Although you probably could derive from FeatureLayer, your existing approach is fine - once you've created a GraphicsLayer you can query the Graphics attributes using Lync. There's no "visible" property as such but you could either remove them from the Graphics collection of the GraphicsLayer, or clear the symbol on that specific Graphic or change your renderer such that specific Graphics are not visible.
A FeatureLayer in the current API is something that's sourced from a FeatureService (local or online) which provides schema, geometries, attributes, rendering information, prototype/template features for editing, etc. In the future we hope to extend the feature layer concept to include additional local datasources, although this would be done within the new .NET SDK (http://blogs.esri.com/esri/arcgis/2013/07/05/the-history-and-future-of-the-arcgis-sdks-for-net/).
There are a few things to remember - if you're populating a GraphicsLayer you should ideally use the GraphicsSource property, or at least AddRange, as the most efficient way of getting the Graphics into the layer. Also, assigning a Renderer to the entire layer is more efficient than assigning individual Symbols. By default, if you assign a symbol to Graphic which already has a renderer, the symbol will override the renderer. Lastly, if you're updating the coordinates of the point objects - it's more efficient to use the MoveTo method rather than directly modifying the coordinates.
As far as I know, there are no solutions at the moment that would enable Runtime SDK to work directly with SQLite.
One thing that might be worth to check is that could you create one mpk with needed Feature Services and then use that as a mediator between the SQLite and Map. You could manage the content of the layers in the map package by hand and then use Runtime SDK to work directly with those local services. Ofc, you need to move changes to the SQLite db from map package too. Let me know if you need help to test the concept.
If using Map Package is not an option then I think you need to handle all the querying by yourself using directly SQLite stuff.
Although you probably could derive from FeatureLayer, your existing approach is fine - once you've created a GraphicsLayer you can query the Graphics attributes using Lync. There's no "visible" property as such but you could either remove them from the Graphics collection of the GraphicsLayer, or clear the symbol on that specific Graphic or change your renderer such that specific Graphics are not visible.
A FeatureLayer in the current API is something that's sourced from a FeatureService (local or online) which provides schema, geometries, attributes, rendering information, prototype/template features for editing, etc. In the future we hope to extend the feature layer concept to include additional local datasources, although this would be done within the new .NET SDK (http://blogs.esri.com/esri/arcgis/2013/07/05/the-history-and-future-of-the-arcgis-sdks-for-net/).
There are a few things to remember - if you're populating a GraphicsLayer you should ideally use the GraphicsSource property, or at least AddRange, as the most efficient way of getting the Graphics into the layer. Also, assigning a Renderer to the entire layer is more efficient than assigning individual Symbols. By default, if you assign a symbol to Graphic which already has a renderer, the symbol will override the renderer. Lastly, if you're updating the coordinates of the point objects - it's more efficient to use the MoveTo method rather than directly modifying the coordinates.
Unfortunately I can't go into greater detail at this time on the improved local data access for 10.2.1 - but you should note that what we do introduce will be in the new .NET SDK mentioned in the previous post rather than in the existing WPF SDK. The new .NET SDK will be out in beta in Q4.
