iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
Clearly... there is something wrong here. Either that... or we're breaking some rules from Android's guidelines. Please take a look at MyInventory_MasterDetail that we modified. Specifically, adding a menu layout named "sold_actions.axml" and modified ItemListFragment.cs to specify MenuLayoutId. Please run the sample on Anroid Tablet for better viewing.
<?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/MarkSoldButton" android:title="@string/MarkAsSold" android:showAsAction="ifRoom|withText" /> </menu>
protected override int MenuLayoutId { get { return Resource.Menu.sold_actions; } }
Please download the solution by clicking here.
Awesome! Yes, we've though about the first option you mentioned... but that's not going to work on our design, because the fields can be overridden on the client side. Looks like the second option is the way to go. And yes, we also need changes to related entities as you anticipated. We'll give it a try and see how it's going to work.
Many thanks!
Hi Leo,
Thank you for the sample. Do you have a flowchart or a document that illustrates the flow of events or delegates used by the EntityContextProvider? We need to understand how and where to put processes within these events as necessary. The sample you have given us illustrates calculations done on WebApi layer, not on the database itself. It does make sense to process calculations that way if calculations are handled on WebApi controller. However, we need to fetch calculated values after the changes have been saved to the database, not before. The reason being... there are calculations being processed ON AFTER UPDATE triggers that rely on incoming data from client side.
Okay, let's try to make things simpler. Let's forget about related entities for the time being. Take a look at the table below, with a trigger. This sample indicates that Gross and CommissionAmount are calculated via trigger. In this design, the mentioned fields can be overriden in case the actual cash is not the same with the calculated value. Be that as it may, whatever values generated for these fields should also be fetched by the EntityContextProvider on its return to the client.
USE [IntersoftSample] GO CREATE TABLE [dbo].[Collection]( [CollectionId] [bigint] IDENTITY(1,1) NOT NULL PRIMARY KEY, [Amount] [money] NOT NULL, [Refund] [money] NULL, [Gross] [money] NULL, [CommissionRate] [smallint] NOT NULL, [CommissionAmount] [money] NULL ) GO CREATE TRIGGER [dbo].[PostCommission] ON [dbo].[Collection] AFTER UPDATE AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for trigger here IF (NOT UPDATE(Gross) AND NOT UPDATE(CommissionAmount)) BEGIN UPDATE [dbo].[Collection] SET Gross = INSERTED.Amount - ISNULL(INSERTED.Refund, 0), CommissionAmount = (INSERTED.CommissionRate / 100.00) * (INSERTED.Amount - ISNULL(INSERTED.Refund, 0)) FROM [dbo].[Collection] CO INNER JOIN INSERTED ON CO.CollectionId = INSERTED.CollectionId END END GO
Based on the current behavior of EntityContextProvider, is it capable of fetching the calculated values for Gross and CommissionAmount in this scenario if an update is made from client side for Amount, Refund, and/or CommissionRate? Please advise.
Thanks!
Hi Arief,
Can you confirm the same for DataListViewModelBase? The usual bindings are set, and working on iOS... except for Android. BindingProvider contains pairing of both ButtonId and Commands. The buttons are defined for Android using a menu axml, with the same IDs used with that of the iOS' view controllers. Both are sharing the same viewmodel, as intended for cross platform configurations. The only difference between the two platforms is that... on iOS we have to use RegisterViewIdentifier for the button IDs, and we don;t see how that is being used with Android except for the "this.RegisterViewIdentifier("TableView", this.ListView);" statement. I'm guessing the button IDs are registered with view identifier automatically for Android.
Kindly test this scenario on ListFragment and DataListViewModelBase. As already mentioned, setting the return value of all CanExecute funtions to a static value of true will enable the buttons at runtime, but doesn't change states using dynamic calls. Breakpoints to CanExecute functions suggest that the functions are being called; however, regardless of the values... the buttons don't change to Enabled/Disabled states. That being said, RaiseCanExecuteChanged method are also being called for each delegate commands, but it's not helping.
The current configuration (BindingProvider, ViewModel) works on iOS, but not on Android... so it may be due to the VIEW being used.
Hi,
Any updates on this? Thanks!
Gracias!
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname