I'm wondering if this architecture is possible for an Windows Store application.
To resume briefly, i have a main apps which contain components (those can have view/ViewModel...). Those components are accessible via an hub in the main project. To ensures maintainability, i'd like to order my components as subprojects of my solution. I'd like to be able to debug through subproject.
Here is an example :
Solution
MainProject (hub)
subProject1 (hubtile1)
views
viewModels
subProject2 (hubtile2)
views
viewModels
... and so on.
The question is : how to achieve that ?
Is it possible to include a subproject as view with viewmodel linked in ? in that way i (or other) could dev each subproject separately.
If it's possible will my subProject would be able to discuss with each other (like subProject1 wants to share some infos with subProject2) ?
Thanks in advance for any hint :-)
I would not create a project for every single hub. It's not best practise and will slow down Visual Studio. I saw such a project...
I would suggest a structure like:
BusinessLogic (project)
DataAccess (project)
UI (project)
Assets
Controls
Pages
Styles
UserControls
ViewModels
With this approach you'll also preventing to have too many namespaces.
Related
I have a several Xamarin forms projects that make up a suite of applications. In each project there is the XF class library with all of my views, viewmodels etc as well as the stub projects for all of the target platforms.
To share common code, views across all of the projects in the suite of applications, I also have a separate class library where I share view / code that are common across all projects in the application suite.
I am trying to figure out if there is a way to move all of my style's definitions from the App.xaml file of each project into the class library that is shared across all the projects. The goal is to have one set of styles that can be updated and the update will apply to all projects in the suite of applications.
Any ideas? I was thinking I might be able to add the programmatically in c# class but I was more looking for a way to have it in XAML so moving from the App.xaml to the new approach would not require a large change to the projects.
I'm looking into porting an existing enterprise app to iPad. One of the key requirements is that there is a basic functioning app that needs to be highly customizable/extensible. Also, the people working on the customizations and extensions are not part of the product team and do not have access to the base product's code (only interfaces, docs and the binaries). To achieve this, the current application uses a component based architecture where well defined components are used to compose the UI. For a given customer any of these components can be either extended and used instead of the out of the box ones or simply swapped with a new component that adheres to the interface.
Are there libraries in cocoa-touch that support a component model architecture ? (composing the app through a registry/configuration that can easily edited by others than the team developers)
Sebi
Perhaps you can create a root view controller and inject polymorphic children with: https://github.com/jasperblues/Typhoon
I have some shared code I want to reuse in my Xcode projects. The easiest way is using a shared framework. I must make headers public in order to reuse the framework in my projects.
Now: since the framework must be copied inside final products, is there an automatic way to prevent public headers from being copied too? Of course I can do this manually, but an automated trick would be amazing :)
Thank you
IIRC, you can do all that with frameworks. Frameworks can be installed system-wide, or inside the application package. If you haven't read it yet, it's in the docs : Embedding a Private Framework in Your Application Bundle
Basically, you're going to make two variants of your framework, one for developing client applications, one for embedding inside those applications. In Xcode you can :
either setup two framework targets, and change the Header files' roles as wanted (public or private)
or use the PUBLIC_HEADERS_FOLDER_PATH build setting with different values in two build configurations. (Say, "Development" and "Deployment"). Your header files will end up in different locations this way.
I haven't done this for a long time, but I don't have particularly good memories of embedded frameworks. What type of code are you reusing exactly? Is this common, all-purpose code? Or is it a whole, coherent project?
If you're just trying to reuse generic code, you might be better off using a simple, old-school .a static library with a headers folder, or even better, a static framework. (Which is just a static library inside a framework bundle)
I'm new to mono and working through the Mono For Android tutorials. Can anyone point me to some documentation which explains the meaning of the [Application] tag above my classes?... Here's my issue:
I have come accross an issue where I have created two seperate classes App1.cs & App2.cs, both of these extend the Application Class (Public Class App1 : Application).. etc.
There is a tag above this declaration [Application] which seems to be causing deployment issues, although it builds fine. If I comment one of these out, the application builds and deploys fine.
I have searched for info on these tags, but as yet cannot find anything in the search, FAQ's or on google... I guess the square brackes are causing me search problems. Any help would be great...
Thanks
C
In Android applications you can subclass the Application class in order to maintain global state in your app. An app can have at most one Application class, and it is shared throughout the app. In order to register your Application class it needs to be registered in AndroidManifest.xml (this applies to any Android component). Mono for Android uses attributes to generate the manifest during compilation, so any class decorated with ApplicationAttribute will generate configuration at build time.
Since only one Application class is allowed, this would explain the problems you are seeing when you try to register two of them. My guess (without having context into what you're trying to do here) is that you probably want to subclass Activity for these classes instead of Application.
I have two projects which share quite a portion of logic, localizations, properties and even views (Logindialog, Popovers etc.). I now want to put the intersecting set into a new project, which should be used as some sort of common library.
I want to keep the common project as a git submodule in my other projects:
Project A
- Classes
- Resources
- CommonLibrary (git submodule)
Project B
- Classes
- Resources
- SomeBSpecificFolder
- CommonLibrary (git submodule)
The CommonLibrary would now probably also be it's own Xcode project. I am not sure now how I should tackle this problem. I know of the following options:
Use a library (.a-file and .h file)
TestFlight e.g. does it like this. I quite like the fact that I can just compile against a binary and don't "see" the source. So just a clean API for doing things.
Include the whole project (Project dependency)
Three20 does it like this and I find it quite annoying to have some 6 subprojects in my project. However in my case it would only be one project, so this might be an option too.
Just have loose source files without a project inside the CommonLibrary folder and manually add them to both of the projects. The project would then compile the sources along with any project-specific sources. This looks a big like a workaround to me and I guess I would prefer to somehow bundle the common sources. Also if there are new files, I always have to add them to the other projects.
Can you guys give me some advice and tell me if there is another option or what you think are the advantages and disadvantages about these approaches?
Thanks a lot for your help!
From a clean, non-application specific perspective, you should be looking to create a library/ framework. This provides:
the reusability you want
without extending build time of dependent projects,
while maintaining consistency of the code base (maintainability),
keeping your API consistent across using projects and
managing dependencies between layers
In terms of Xcode, if I remember correctly from my OpenStep days, you should be looking to create a new Framework project which will provide the relevant makefiles for that type of project. A cursory surf produced:
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html
and the slightly more friendly:
http://atastypixel.com/blog/creating-applications-in-xcode-using-frameworks/
Furthermore, you might actually want to layer your frameworks to further improve reusability. That is, don't just create one framework, create one per tier: put common code in a Foundation framework, UI/ AppKit-based classes in a UI framework, etc. This way, your frameworks are relevant to whatever tier your using classes and projects live.
For instance, if you have a category on some foundation class, put it in a common/ foundation framework that can be reused by any other common/ foundation classes and projects you build. If you were to put it in a UI-tier framework with UI libraries and dependencies then it couldn't be reused by your foundation level projects (as these can't have UI-level dependencies).
Hope this helps...
I found a project called RestKit on github which seems to be a good example for a third-party framework, which can be included in an existing project.
The readme and the wiki describe nicely which steps need to be done in order to include the project. I guess this is a good starting point for someone who want to create a framework himself.