In porting my WPF MVVM app to MvvmCross, what would be the recommended approach for persistent user settings in the Core assembly? Currently I'm using Properties.Settings for this task. Ideally, I'd like a solution that can play nicely with ClickOnce upgrades on Windows.
Thanks!
If you only want to support WPF, then you could continue using properties.settings.
If you want to support settings using native techniques on other platforms as well, then you could create an interface/abstraction for your settings and then use dependency injection to inject an appropriate settings implementation on each platform. You could do this in a plugin if you wanted to - but for getting started it's easiest to start by injecting this in your UI projects in Setup.cs (for how to build a plugin, see https://speakerdeck.com/cirrious/plugins-in-mvvmcross)
What I would probably do... is to use a portable settings implementation - either using a simple JSON file or using a small SQLite database (accessed via SQLite-net). This would enable you to reuse exactly the same code on all platforms. I don't know how this would work with ClickOnce (I don't know much about ClickOnce) but I'm assuming ClickOnce would preserve these data files during upgrades.
For portably saving a JSON file, see https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20CirriousConference/Cirrious.Conference.Core/Models/FavoritesSaver.cs
For using SQLite-net, see https://speakerdeck.com/cirrious/using-sqlite-dot-net-in-mvvmcross - but be aware that the nuget packages for SQLite-net still suffer from the open issue on x64/x86/ARM differences - see How to distribute processor-specific WindowsStore assemblies with nuget :/
Related
I am new to sakai, i want to add my own tool in sakai source code like announcement,syllabus...etc That tool having some my own functionality for this what i have to do, how can i develop my own tool in sakai.
Thanks.
Use one of the archetypes to get you started, then customise it. When you are comfortable you can change the UI layer to be whatever you like.
https://confluence.sakaiproject.org/display/BOOT/Developer+Tools
If you are looking for a solid "base" tool shell to begin with tool development my recommendation would be to start here: "Sakai Wicket Maven Archetype". There are a few other very good archetypes available but are often outdated and may cause you some problems based on my experience. This has been the one I've had the most success with.
This uses Wicket but does not mean you have to use Wicket to develop further with it. Make sure to pull the 1.2 version as last check the binaries for the others were not available yet so replace -DarchetypeVersion=1.4.1 with -DarchetypeVersion=1.2 It will compile and deploy successfully as a tool "as-is" that you can modify as needed. It also allows you to code in Java to directly access the sakai API and pull from its database or even add your own tables. I've successfully used it with NetBeans 8.0.1 and MySQL 5.6 under Windows 7 with Maven 3.2.3 and Sakai 10.1.
The code is well-documented and is no-frills but with enough varied functional use examples to allow you to do "almost" anything you want. The wicket manual is 600+ pages but in my experience you should be able to accomplish a lot just by looking at the code in the archetype.
Together with my team I'm developing multiple native plugins based on Trigger.io. Since the recent changes I'm not completely sure on the workflow and cannot find anything about it in the documentation either. Some questions that arise:
1) Should one set of inspector projects be used for all the plugins or should each plugin has its own set?
2) Which parts of the inspector projects should be maintained via version control, which should remain local? (fyi: we use SVN)
3) (Android) When using one inspector project for each plugin, whats the best way to import them all as Java projects in Eclipse? Note: each inspector project has 3 sub projects which have the same name across different plugins, so they'd have to renamed? Assuming I have 5 plugins in development, that'd mean that I have to import 15 Java projects into Eclipse. Is this really how it's meant to be?
The most effective way to develop plugins is still something we're working on, how things are right now is probably not as good as it could be (especially for developing multiple plugins), but as things are right now:
1) Each plugin should have its own set of inspector projects.
2) The majority of what the Toolkit puts in the plugins folder is probably best in version control. Things you can safely ignore are the .trigger folder and any bin, gen, or build folders in the inspector projects. If you are trying to keep less files in version control the things you definitely need are the assets/src folder in the ForgeInspector, and any of your own source in ForgeModule, the rest of the inspector project should be regenerated by the Toolkit.
3) I'd recommend using an eclipse workspace per plugin, as the Toolkit regenerates a lot of the code when you update the inspector I don't think it is currently possible to rename the projects.
I thought I'd include a quick overview of what the 3 projects are and why there are 3:
ForgeCore - This is the pre-build core library for Trigger.io apps, its used by both ForgeInspector and ForgeModule so it needs to be a separate project that can be referenced by both
ForgeInspector - This is meant to replicate as closely as possible how your plugin will actually be used, so is basically a stripped down Trigger.io app, its separate to ForgeModule so that you can see what code is in your plugin and what code needs to be put into build_steps.json so it will also be applied to a real Trigger.io app at build time.
ForgeModule - This contains your plugin code
I'm currently working on a project which source code should be as portable as possible; that is, the project (in C#, but it is not very relevant) represent an application that should be executed on Android (with Mono-Android), on iPhone (with MonoTouch) and WinMobile (with official Compact Framework). Without going into details, the corresponding MSBuild solution consists of an independent-platform library (from a source code point of view, at least) which declare various interfaces and classes that represent an abstraction of each feature that is not common to the various platform (i.e. the UI). In addition, there are a corresponding library that specialize (for each platform) the "base library"; the effective application executable is a program that uses the abstraction and the common standard libraries.
Developing on WinMobile and Android is not really a problem: Mono-Android add-in can be installed on VS 2010, so both platforms can be handled with MS VS.
Initially the solution was created in VS, so the initial configuration and the related projects (Android and WinMobile) are automatically generated.
After that I've imported the solution in MonoDevelop under Mac (the only platform that is officially supported by MonoTouch), and I've created the project for the iPhone library; switching the configuration to generate the assemblies (iPhoneSimulator) the "base library" was not possible to compile due to a missing project type configuration; specifically, the GUID used by MonoTouch for <ProjectTypeGuids> is {E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}; adding this GUID I can now compile "base library" in MonoDevelop.
The problem arises when I try to re-import the solution in VS: since there's no Windows version of MonoTouch, VS cannot find the add-in for the specified project type, and the project doesn't load.
Looking to the specifications of MSBuild project file, it seems that there are tons of options that cannot be set or modified within the project/solution editor in VS; however the format is quite complicated and now I'm asking your help!
Is there a way to specify in the project file that a project type is present only if a particular configuration is selected independently to which is the environment I'm using?
The general approach is something like this; a condition that progressivly builds your property, referencing any value the property already may have:
<ProjectTypeGuids
Condition="'$(BuildingInsideVisualStudio)' != 'true'"
>;{E613F3A2-FE9C-494F-B74E-F63BCB86FEA6}"</ProjectTypeGuids>
<ProjectTypeGuids>{OTHER-GUIDS-HERE}$(ProjectTypeGuids)</ProjectTypeGuids>
This will detect the VS condition (when building) and omit the unkonwn guid. I'm not sure however if it will work when the project is opened, this property might only apply to building. There may be a similar "sentinal" property for building on Mono, and you can reverse the condition.
I solved an unrelated, but very similar issue of cross-platform development by excluding the files that presented themselves as cranky when going between Linux and Windows. I have my project under source control and utilized that to keep things working cooperatively.
http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html
It's not a 1-to-1 for your issue, but it might give you clues/ideas on how to solve your problem.
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.
I'm work in an aplication that need be capable of support plugins, but i dont know how this work.
See Design Pattern for implementing plugins in your application?
The answers tend to get very platform specific. It also depends on how much control of your core app data and logic the plugin must have.
The C++ QT4 book has a good description of adding a file-type plugin to it's architecture, there area also a bunch of modeling apps (openscenegraph, blender, povray ) that have good documentation for their plugin architectures.
You need to design your application's API in such a way that plugins can be created, and you need to add the necessary plugin management interfaces and supporting code to invoke the plugins. There is no catch-all way of managing plugins.
Take a look at the open source application called Rawr (c#). Each addin is a seperate .dll and the main app uses reflection to access the code. Very nicely done.
www.codeplex.com/Rawr