Our Team is trying to build multiple Windows 8 Store Apps for an enterprise.
How do we maintain a common session for all apps(where we store data which need to be shared)?
How do we enable direct interaction between the apps developed i.e. sharing objects or string(JSON) among the apps?
There is not built in way to do this. Realistically you probably have three options to share data between applications.
The first is to use the cloud / web services. This makes the most sense as you'd have full control about what is shared, authentication etc. Using libraries such as SignalR could let you add real time functionality between the applications as well as multiple users.
The Share contract, by using custom data formats you could enable the apps to share specialised data between each of them. This can make sense if the user has a set of data they want to send to another application to enable a quick piece of workflow as the Share target is only partially launched. This also is limited in that it's enabled by user action.
Custom protocol handlers, by giving each app it's only protocol my-custom-app:///some-action?param1=value etc then you can pass data between apps, note this launches the app in question when you launch that uri. This would be best for more longer running scenarios.
I'd suggest a combination of all three depending on the user action. Cloud services to store the data for the user and then a mixture of Share and Protocol to enable to the user to smartly move the apps seamlessly.
Here exactly the same question as yours. In short: there is no such ability. Sometimes I think that it will be easier to share data via Internet that in device.
Related
Is there any way to work with data in shared web credentials directly, like with keychain, without showing popups on SecAddSharedWebCredential and SecRequestSharedWebCredential?
Or are there any other methods to work with it?
I want to share some data (string) between apps with different development teams.
I will recommend you to use the KeychainAccess which is a simple swift wrapper. And using Keychain is the best way to store small pieces of data that are critical to your app, like secrets and passwords.
Also the tutorial from raywenderlich would help you use the Keychain Services API.
App groups can be an option for your use case. Read below the apple API documentation and medium post
App Groups
Use a shared app group to share data/files between two/more apps or containing apps. An app group creates a secure container that multiple processes can access. Normally, each process runs in its own sandbox environment, but an app group lets both processes share a common directory.
Apple API docs - https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_application-groups
https://medium.com/#dinesh.kachhot/different-ways-to-share-data-between-apps-de75a0a46d4a
Also here is another stackoverflow post answering similar question - Communicating and persisting data between apps with App Groups
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
We have a back end API, running ASP.Net Core, with two front ends: A SPA web site (Vuejs) and a progressive web page (for mobile users). The front ends are basically only client code and all services are on different domains. We don't use cookies as authentication uses bearer tokens.
We've been playing with Application Insights for monitoring, but as the documentation is not very descriptive for our situations, I would like to get some more inputs for what is the best strategy and possibilities for:
Tracking users and metrics without cookies from e.g. the button click in the applications to the server call, Entity Framework/SQL query (I see that this is currently not supported, How to enable dependency tracking with Application Insights in an Asp.Net Core project), processing data and presentation of the result on the client.
Separating calls from mobile and standard web in an easy manner in Application Insights queries. Any way to show this in the standard charts that show up initially would be beneficial.
Making sure that our strategy will also fit in situations where other external clients will access the API, and we should be able to identify these easily, and see how much load they are creating for the system.
Doing all of the above with the least amount of code.
this might be worthy of several independent questions if you want specifics on any of them. (and generally your last bullet is always implied, isn't it? :))
What have you tried so far? most of the "best way for you" kinds of things are going to be opinions though.
For general answers:
re: tracking users...
If you're already doing user info/auth for other purposes, you'd just set the various context.user.* fields with the info you have on the incoming request's telemetry context. all other telemetry that occurs using that same telemetry context would then inerit whatever user info you already have.
re: separating calls from mobile and standard...
if you're already doing this as different services/domains, and you are already using the same instrumentation key for both places, then the domain/host info of pageviews or requests is already there, you can filter/group on this in the portal or make custom queries in the analytics portal to analyze that way. if you know which site it is regardless of the host, you could add that as custom properties in the telemetry context, you could also do that to avoid dealing with host info.
re: external callers via an api
similarly, if you're already exposing an api and using auth, you should (ideally) already know who the inbound callers are, and you can set that info in custom properties as well.
In general, custom properties (string:string key value pairs) and custom metrics (string:double key value pairs) are your friends. you can set them on contexts so all the events generated in that context inherit the same properties, you can explicitly set them on individual TrackEvent (or any of the other Track* calls) to send specific properties/metrics with any single event.
You can also use telemetry initializers to augment or filter any telemetry that's being generated automatically (like requests or dependencies on the server side, or page views and ajax dependencies client side)
The question is more targeted at server side development.
When writing a REST API, I want to write it in such a way that it can be consumed by both desktop and mobile applications.
Could see two possible approaches:
Each API should support pagination and the responsibility should be delegated to the client of how much data should be fetched in one go. So , mobile apps will ask for fewer pages in one go and desktop applications will ask for more.
Separate APIs for mobile devices hosted separately. The front-end web server can check the user agent (i.e. source from where is request is coming) and if it's a mobile device, then re-route the request to the server hosting the APIs for mobile devices.
Interested to know more strategies around this.
Appreciate your inputs.
I would suggest a bit of both (1) and (2), here's how.
Instead of re-building whole new api for mobile itself, Have adapters for all the supported devices. i.e have a layer on top of you REST API implementation which renders/instructs the underlying service to return the content suitable for selected mobile device.
coming to pagination, you can parameterize the pagination as an input from the Abstraction mentioned above.
I would recommend something closer to option (1). If the main difference between the clients will be the amount of data they request at a time, it seems trivial to add some kind of query parameter or HTTP header to the REST API indicating how many records to return, for instance.
Relying on checking the User-Agent header may require you to maintain a list of known client user agents and match against them, which would be an additional maintenance cost of a separate API.
Is it possible to use Google Analytics API's to track Mac OSX applications?
If not could any one suggest me an alternative for Google Analytics.
Google Analytics is designed to work with web applications not for desktop apps. Although it might be possible to collect info about your application and send it to your Google Analytic account but the amount of work required to retrofit might be better spent, building your own Analytic solution.
A good starting point would be to create a simple web service, which collects information regarding clicks. Then rewrite your application to call that web service on every click within your application.
You would ideally want to store this information locally and submit it to the web service in batches. You would also want to design the application, so that if you ever shut down the web service, the application would still be able to operate.
UPDATE: As pointed out in the comments by Václav Slavík, they have added apps analytics for iOS/Android.
I made a simple set of classes for doing this:
https://github.com/stephenlind/SimpleCocoaGoogleAnalytics
Google Analytics is not only for web applications, but also for mobile. It's available on the platform like android, iOS, etc. If you want to track your MAC OS X application, you can choose DeskAppTrack or DeskMetrics. DeskAppTrack is only available on MAC. It provide a professional data statistical analysis and it's free. While DeskMetrics is available on MAC and Windows. Either one is ok.
This really depends on how detailed you want to get. If you are are truly looking for analytics with detail and control flow data, you are better suited to created your own web service, as mentioned.
However, if you simply want to know a small number of operations, that occur at a small volume, i.e. when the app is launched (a quick and dirty solution): then in theory you could create a landing page on your site that contains a minimal head section, and a blank body, and then load the URL with an NSURL when you want to trigger the action.
Of course, you would have to include the google analytics tracking codes in the header, and you may need to load an off-screen webview to get the javascript to run. Like I said, quick and dirty.
In either case, you want to make sure the application will continue to perform properly, even if the web service / page is not present.