I have seen online various functions attempting to determine my PowerApps release number and the specific version for my canvas app, but none have worked for me. Do you know how to obtain my Power Apps release version number, and my specific app version number?
This is the best I've found so far but it only outputs a a version date that doesn't even accurately reflect my last published app version. Maybe it is the PowerApps release date, but that's still not what I want:
First(Filter(PowerAppsforMakers.GetApps().value, properties.displayName = "YourAppName")).properties.appVersion
NOTE: You have to fill "YourAppName" with your specific app name. Also, to be able to use the above function and have your app compile, then starting from the top menu in your PowerApps editing session, you have to go to "View" | "Data sources" | "Add data source", and then click "New connection". Search for "Power Apps for Makers" and sign in as required.
Related
First off I would like to say your product is amazing! Has made the job of inheriting an old DNN instance a much more intuitive experience.
Apologies if this is really simple thing I'm missing but I'm at a dead end after scouring the docs and internet.
I'm using Evoq content and up until the start of the week the publishing workflow had been working fine rich text WISIWIG fields but it seems something has changed. Now when publishing changes any apps that are embedded in rich content fields display the demo item when not logged in.
I've recreated the issue on a smaller scale to illustrate the problem:
When logged in it looks as expected - on the left is a button that's placed directly onto the page, on the right is a button inside a rich text field:
logged in
And when logged out:
logged out
As you can see the button that is embedded as a rich text field is displaying the demo item.
I've gone through all of the content items and ensured that they are set to publish and not draft or hide and ensured the page is set to published in DNN.
Aldo I've double checked how the fields are setup but as this was working previously, I'm doubtful that this is the issue but for clarity here is how the fields look in the model:
Rich text field model
And it's rendered to the page using:
#{
var renderSvc = GetService<IRenderService>();
}
#renderSvc.All(Content, field: "BodyContentBlocks", merge: Content.Body)
I've been scouring the docs and internet for hints of what might be going on but the closest I could find was this thread on github but it doesn't seem to be quite the same issue.
Any help would be massively apricated as this issue has cropped up just before moving to our production server (as they always do!) after working as expected for a couple of months. Let me know if you need any more info from me and thanks for your time.
Evoq has a page-workflow feature which is technically undocumented. 2sxc got a sponsor a few years ago who paid for the implementation but there are limitations to it. Some background:
Some data in 2sxc can be clearly assigned to a module or page - such as content added directly
Other data cannot be assigned to a page - such as a blog post
Because of this, the logic is to first determine if something is partOfPage and if yes - and workflow is active - then it will be set to be a draft. This way the end users don't see it.
Upon page-publish, everything that is partOfPage will be published, so the draft will become the live data.
I assume the detection of this was never implemented for inner content - I think inner-content was actually developed later. Because of this, I assume the toolbars for the inner-content-item tell the UI it's part of the page (resulting in draft), but the publish cycle doesn't know about this, since it's internally a sub-entity (which is just like a tag on a blog - not part of a page).
This is difficult to fix. A proper fix would require 2sxc to be modified to make sure that inner-content is never seen as part-of-page, OR that it's taken into account when publishing. Both of these options would probably take ca. 3 days of dev on 2sxc side and would only happen if we have a sponsor.
A workaround is to disable the Evoq-integration so the page publishing wouldn't happen. I believe there is a feature for this - and AFAIK you don't even have to become a Patron (which I highly recommend to support our thousands of hours of work):
Or you could manually try to publish it, but that will be difficult. Note that most of us will be on x-mas vacation so we won't be answering questions till mid Jan.
Summary of options
Avoid inner content for now
Disable Evoq Page Workflow in 2sxc
Manually publish the items (very difficult, needs super-user permissions because it's an unusual thing to publish)
Get some budget ca. 3 days to sponsor the feature https://2sxc.org/contact but wait till end of January
A mix of short-term solution + sponsoring
Sorry for the delay on this, I've been waiting for a decision. I'm going to close the question as we have been able to work around the issue for now with the help of your last comment. Avoiding inner content is working well enough for our use case. Thanks for your time and help and for making an amazing product!
I am getting frustrated with Google's Play store. My app won't appear in searches (at all). There isn't a "new this week" section where users can find new stuff from indie devs such as myself. Top results usually include hillarious reviews that smell fishy
I contacted Google and they said that I can pay them money to appear in top searches (via ads) and this way improve my "market strategy". I am just trying to share my free app so that others can use it, I have no market strategy
As a result, I am going to focus on my Apple Store version (which is performing much better). I am also exploring the option of publishing on Galaxy Store, Huawei Store, etc
I tried uploading to Galaxy Store but upon submitting the app I get the following error:
The registered binaries do not meet the category conditions for Galaxy Specials
Looking here I can see that something needs to be added in the manifest file. Is there a way to do this via build hints in CodenameOne? I also read that a "Galaxy SDK" needs to be added somewhere. Is this a prerquisite and if so, how would one add it in CodenameOne?
I haven't tried this but this might work, add the build hint:
android.xpermissions=<uses-permission android:name=”com.samsung.android.providers.context.permission.WRITE_USE_APP_FEATURE_SURVEY”/>
If the build hint already exists then just tack this string to its ending.
Basically, we are building a small apps for mobile that list and display all applications/builds/details availables on the server. The listing is between 3-25 apps and each apps on the display occupy about 60 pixel hight with nice UI.
Apps 1 version ABC build date...
Details of the apps here (1-100 lines)
Apps 2 version ABC build date...
Details of the apps here (1-100 lines)
Apps 3 version ABC build date...
Details of the apps here (1-100 lines)
Apps 4 version ABC build date...
Details of the apps here (1-100 lines)
etc.
The listing order/size may change few times during a day (1-3). Is it good practice the just update the listing without any warning?
We have concerns if user is reading details for exemple while the refresh occured, the refresh will cause a scroll back to top. etc. We are talking about "good practice" of apps behavior.
Any comment or suggestion would be appreciated.
thanks,
I think it's all right to refresh data on an application if the goal of the application is to show the most actual data at all times.
But it is VERY important to give a clear and noticeable feed back to the user that the data has been refreshed, with an animation, some color changing or just an effect that goes well with the application.
Another option (and you have a great example just here in Browser Stack) is to tell the user that there is new data, and make them do something to update it.
Like a small prompt at the top of the screen that says "New data is available, tap here to update". That way you are sure that the user is 100% aware that data is being pushed to the application again, and that he agrees to do it.
Hope this helps.
I have a very critial business application presently running using Winforms.
The application is a very core UI shell. It accepts input data, calls a webservice on my server to do the computation, displays the results on the winforms app and finally send a print stream to the printer.
Presently the application is deployed using Click-once.
Moving forward, I am trying to contemplate wheather I should move the application into a Silverlight application. Couple of reasons I am thinking silverlight.
Gives clients the feel that it is a cloud based solution.
Can be accessed from any PC. While the clickonce app is able to do this as well, they have to install an app, and when updates are available they have to click "Yes" to update.
The application presently has a drop down list of customers, this list has expanded to over 3000 records. Scrolling through the list is very painful. With Silverlight I am thinking of the auto complete ability.
Out of the browser - this will be handy for those users who use the app daily.
I haven't used Silverlight previous hence looking for some expert advice on a few things:
Printing - does silverlight allow sending raw print data to the printer. The application prints to a Zebra Thermal label printer. I have to send raw bytes to the printer with the commands. Can this be done with SL, or will it always prompt the "Print" dialog?
Out of browser - when SL apps are installed as out of browser, how to updates come through, does the app update automatically or is the user prompted to opt for update?
Printing -- using the PrintDocument API your user will be prompted for a print dialog. Currently using that API there is no way to suppress this. It isn't ideal for high-volume thermal situations (like pharmacies, shipping warehouses, etc.). You could use the trusted application mode and peek out into COM and do whatever you want with the printer.
The update happens when the application asks for it. There is an API to use and, once called, if an update exists it is downloaded -- no prompt to the user as an option. If an update is found you can alert the user to restart or that on the next restart they will have the updated application.
Autocomplete is not something that can only be done in Silverlight. Your ClickOnce app is already out-of-browser. And printing via raw bytes to a thermal printer is something that would not be easily engineered in Silverlight.
Not trying to sound negative, but in sum it sounds like you're better off simply working on enhancing the app that you already have.
I am currently running a SL3 project where we are in a highly iterative development mode with about 25 active test customers. I am making small changes at a clip of about 4 new builds per day. It is important to know this application is mission critical line of business for these 25 people, it is the tool they use all day to do their work so they are using it constantly and often launch their browser and the app in the morning and never close it until the end of the day.
The challenge is that when I make an update to the application I have no clean way to notify the users, in most cases this is ok as it is rare that I introduce a data contract change or something that would be a classic 'breaking' change to the app/service. Users keep plugging along and will get the change next time they refresh.
Right now we have resorted to emailing everyone and telling them to force refresh or close the browser and log back in.
Surely there is a better way...
Right now my train of thought is to have a method on the server that compares client xap versions and determines if the client being used is the most up to date, if so I will notify the user and make them update.
What have you done to solve this problem?
One way of doing it is to use a push mechanism (I used Kaazing Websoocket Gateway but any would do). When a new version of the XAP is released a message (either manually entered into the system by admin or automated triggered by XAP file change event) would be sent to all the clients. In the simplest scenario some notification would be shown to a user (telling him that a new version is released and the application needs to refresh) and then the app would refresh (by simply reloading the page) saving user's state if necessary.
If I would do this I would just keep it simple. A configuration value in web.config and a corresponding service method that simply returns that value (the value itself could be anything, but a counter is probably wise). Then you could have your Silverlight app poll that service method at regular intervals. Whenever the value changes (which you would do manually when you deploy a new version), just pop up a dialog telling the user to refresh the browser or log in/out. This way you don't have to force them to refresh every time. If you go with the idea of comparing xap file versions they will always be required to refresh, even for non-breaking changes.
If you want to take it further you could come up with some sort of mechanism to distinguish between different severity levels. For instance, if the new config value would contain the string "update_forced", you could force the users to reload the app by logging them out automatically (a little harsh, perhaps). If it contains the string "update_recommended", just show a little icon at the top right corner saying that there is a new version and that they should upgrade in their own time.
Granted, this was targeted at Silverlight 3, but with the PollingDuplex client and such in the newer versions of Silverlight, you could publish an "Update Now" bit to the clients, and build a mechanism in the client to alert the user that there is an update that is now out... that they should update it shortly, etc. You may even be able, through serialization and such, to save the state that they are in when they close the app to reload it.
We've done stuff similar with a LOB app that we built, so that as users are changing things, the rest of the userbase sees those changes immediately. Next up will be putting the flags in to change authorization and upgrades "on the fly" if you will.